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Quem somos nos? 


Maurício Aniche 

Meu nome é Mauricio Aniche, e trabalho com desenvolvimento de soft- 
ware há por volta de 10 anos. Em boa parte desse tempo, atuei como consultor 
para diferentes empresas do mercado brasileiro e internacional. Com certeza, 
as linguagens mais utilizadas por mim ao longo da minha carreira foram Java, 
C# eC. 

Como sempre pulei de projeto em projeto (e, por consequência, de tec- 
nologia em tecnologia), nunca fui a fundo em nenhuma delas. Pelo contrário, 
sempre foquei em entender princípios que pudessem ser levados de uma para 
outra, para que no fim, o código saísse com qualidade, independente da tec- 
nologia. 

Em meu último ano da graduação, 2007, comecei a ler mais sobre a ideia 
de testes automatizados e TDD. Achei muito interessante e útil a ideia de se 
escrever um programa para testar seu programa, e decidi praticar TDD, por 
conta própria, para entender melhor como ela funcionava. 

Gostei muito do que vi. De 2007 em diante, resolvi praticar, pesquisar 
e divulgar melhor minhas ideias sobre o assunto. Comecei devagar, apenas 
blogando o que estava na minha cabeça e sobre o que gostaria de feedback 
de outros desenvolvedores. Mas para fazer isso de maneira mais decente, re- 
solvi ingressar no programa de Mestrado da Universidade de São Paulo. Lá, 
pesquisei sobre os efeitos da prática de TDD no design de classes. 

Ao longo desse tempo participei da grande maioria dos eventos relaciona- 
dos ao assunto. Palestrei nos principais eventos de métodos ágeis do país 
(como Agile Brazil, Encontro Ágil), de desenvolvimento de software (QCON 
SP e DNAD), entre outros menores. Cheguei a participar de eventos inter- 
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nacionais também; fui o unico palestrante brasileiro no Primeiro Workshop 
Internacional sobre TDD, em 2010, na cidade de Paris. Isso mostra também 
que tenho participado dos eventos académicos. Em 2011, apresentei um es- 
tudo sobre TDD no WBMA (Workshop Brasileiro de Métodos Ageis), e em 
2012, no maior simpósio brasileiro sobre engenharia de software, o SBES. 
Atualmente trabalho pela Caelum, como consultor e instrutor. Também 
sou aluno de doutorado pela Universidade de São Paulo, onde continuo a 
pesquisar sobre a relação dos testes de unidade e qualidade do código. 


Portanto, esse é meu relacionamento com TDD. Nos últimos anos tenho 
olhado-o de todos os pontos de vista possíveis: de praticante, de acadêmico, 
de pesquisador, de apaixonado, de frio. Esse livro é o relato de tudo que 
aprendi nesses últimos anos. 


Andre Cardoso 


Meu nome é Andre Cardoso e minha experiência com o desenvolvimento 
de software ainda é pouca, pelo menos assim considero. Desde de meus 
primeiros contatos com um computador me foi despertada a curiosidade de 
saber como as coisas funcionavam. Isso obviamente me causou muitos erros, 
muitas perdas de arquivos importantíssimos mas me proporcionou também 
muitas coisas boas que carrego comigo até os dias de hoje. Uma delas com 
toda certeza é a sede de conhecimento. 

Como mencionei anteriormente, tenho pouca experiência no desenvolvi- 
mento de software, cerca de 5 anos apenas. No entanto, por iniciar tardia- 
mente, tive de correr de atrás do tempo perdido com muita garra. Não con- 
sidero um fator importantíssimo para minha carreira o fato de ter pouco 
tempo de casa mas sim a intensidade com que busquei me encontrar na área. 

Meus primeiros passos no que seria um chamariz à programação foi por 
volta de 2006, “fuçando” nas entranhas do Linux, alterando diversas fun- 
cionalidades, mas nada de muito avançado ainda. Esta curiosidade me fez es- 
tudar algo relacionado. Encontrei próximo à minha casa, logo que me mudei 
pra Curitiba em 2009, um curso técnico em informática. Diferente dos tradi- 
cionais, seu foco era o desenvolvimento de sistemas, não pensei duas vezes, 
iniciei o mais rápido possível. Em 2010, estava eu de fato iniciando a pro- 
gramar. Meu primeiro contato com uma linguagem de programação que não 


didática apenas foi o Java, e em seguida fui apresentado ao PHP, ao qual me 
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dedico até hoje. Na mesma época em que dei meus primeiros passos na pro- 
gramação, comecei a trabalhar em uma empresa que me deu a possibilidade 
de expandir meus conhecimentos em vários aspectos, e estando lá passei por 
Delphi, Java, C#, Shell Script e diversos bancos de dados. Participei de varios 
projetos da empresa, desde a parte de software até a parte de hardware, que 
era o foco da empresa e, nela, também tive a oportunidade de me aprofundar 
em PHP. 

Ao final de 2011, fui apresentado ao TDD e desde entao venho estudando 
muito mas muito mesmo, ministrando palestras e oficinas, além de, é claro, 
aprimorar o uso em projetos comerciais. Atualmente pratico TDD em tudo 
que posso, não apenas em PHP. 

Um certo dia de 2014, estava eu organizando uma palestra e uma ofic- 
ina sobre TDD para apresentar em um evento de Software Livre (FLISOL) e 
utilizei o livro do Maurício como fonte, além de seus inúmeros artigos em 
seu blog pessoal. Nesta época, achei uma atitude muito justa pedir a permis- 
são do Maurício em utilizá-lo como referência. Meu pedido foi prontamente 
atendido. Logo veio a surpresa, fui convidado a “traduzir” o livro de Java para 
PHP, um convite irrecusável, não acha? Pois bem, naturalmente entendi a 
responsabilidade sobre isso e busquei o meu melhor, preparei todos os exem- 
plos deste livro com muita dedicação e com o que a linguagem PHP oferece 
de melhor atualmente, visto que sua evolução está ocorrendo de forma fan- 
tástica. 

Procuro sempre divulgar a prática de TDD com a organização de oficinas, 
encontros de desenvolvedores e palestras em eventos como Software Freedom 
Day e FLISOL, também divulgo muito a prática em meu blog pessoal, blogs 
de terceiros e comunidades de desenvolvedores, além de meu dia a dia como 
profissional. 
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Prefácio 


TDD é uma das práticas de desenvolvimento de software sugeridas por di- 
versas metodologias ágeis, como XP. A ideia é fazer com que o desenvolvedor 
escreva testes automatizados de maneira constante ao longo do desenvolvi- 
mento. Mas, diferentemente do que estamos acostumados, TDD sugere que 
o desenvolvedor escreva o teste antes mesmo da implementação. 

Essa simples inversão no ciclo traz diversos benefícios para o projeto. Ba- 
terias de testes tendem a ser maiores, cobrindo mais casos, e garantindo uma 
maior qualidade externa. Além disso, escrever testes de unidade forçará o de- 
senvolvedor a escrever um código de melhor qualidade pois, como veremos 
ao longo do livro, para escrever bons testes de unidade, o desenvolvedor é 
obrigado a fazer bom uso de orientação a objetos. 

A prática nos ajuda a escrever um software melhor, com mais qualidade, 
e um código melhor, mais fácil de ser mantido e evoluído. Esses dois pontos 
são importantíssimos em qualquer software, e TDD nos ajuda a alcançá-los. 
Toda prática que ajuda a aumentar a qualidade do software produzido deve 
ser estudada. 

Neste livro, tentei colocar toda a experiência e tudo que aprendi ao longo 
desses últimos anos praticando e pesquisando sobre o assunto. Mostrei tam- 
bém o outro lado da prática, seus efeitos no design de classes, que é muito 
falada mas pouco discutida e explicada. A prática de TDD, quando bem us- 
ada, pode ser bastante produtiva. Mas, como verá ao longo do livro, os prati- 
cantes devem estar sempre alertas às dicas que o teste dará sobre nosso código. 
Aqui, passaremos por eles e o leitor ao final do livro terá em mãos uma nova 
e excelente ferramenta de desenvolvimento. 
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A quem se destina esse livro? 


Esse livro é destinado a desenvolvedores que querem aprender a escrever 
testes de maneira eficiente, e que desejam melhorar ainda mais o código que 
produzem. Neste livro, utilizamos PHP para demonstrar os conceitos dis- 
cutidos, mas você pode facilmente levar as discussões feitas aqui para a sua 
linguagem de programação favorita. Mesmo que você já pratique TDD, tenho 
certeza de que aqui encontrará discussões interessantes sobre como a prática 
dá feedback sobre problemas de acoplamento e coesão, bem como técnicas 
para escrever testes melhores e mais fáceis de serem mantidos. 

Testadores também podem se beneficiar deste livro, entendendo como 
escrever códigos de teste de qualidade, quando ou não usar TDD, e como 
reportar problemas de código para os desenvolvedores. 


Como devo estudar? 


Ao longo do livro, trabalhamos em diversos exemplos, muito similares ao 
mundo real. Todo capítulo possui sua parte prática e parte teórica. Na parte 
prática, muito código de teste é escrito. Na parte teórica, refletimos sobre o 
código que produzimos até aquele momento, o que foi feito de bom, o que foi 
feito de ruim, e melhoramos de acordo. 

O leitor pode refazer todos os códigos produzidos nos capítulos. Praticar 
TDD é essencial para que as ideias fiquem naturais. Além disso, a Caelum 
também disponibiliza um curso online sobre testes automatizados [9], que 
pode ser usado como complemento desse livro. 

Todos os códigos criados neste livro estão no github e podem ser baixados 
através do link a seguir: http://goo.gl/2pS2CA. 


Boa leitura! 
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CAPITULO 1 


Introdução 


Será que testar software é realmente importante? Neste capítulo, discutimos 
um pouco sobre as consequências de software não testado e uma possível 
solução para isso, que hoje é um problema para a sociedade como um todo, 
já que softwares estão em todos os lugares. 


1.1 ERA UMA VEZ UM PROJETO SEM TESTES... 


Durante os anos de 2005 e 2006, trabalhei em um projeto cujo objetivo era 
automatizar todo o processo de postos de gasolina. O sistema deveria tomar 
conta de todo o fluxo: desde a comunicação com as bombas de gasolina, 
liberando ou não o abastecimento, até relatórios de fluxo de caixa e quan- 
tidade de combustível vendido por dia ou por bomba. 

A aplicação era desenvolvida inteira em C e deveria rodar em um mi- 
crodispositivo de 200Mhz de processamento e 2MB de RAM. Nós éramos em 
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4 desenvolvedores, e todos programavam e todos testavam ao mesmo tempo. 
Os testes não eram tão simples de serem feitos, afinal precisávamos simular 
bombas de gasolinas, abastecimentos simultâneos etc. Mas, mesmo assim, 
nos revezávamos e testávamos da forma que conseguíamos. 

Após alguns meses de desenvolvimento, encontramos o primeiro posto 
disposto a participar do piloto da aplicação. Esse posto ficava em Santo 
Domingo, capital da República Dominicana. 

Eu, na época líder técnico dessa equipe, viajei para o lugar com o objetivo 
de acompanhar nosso produto rodando pela primeira vez. Fizemos a insta- 
lação do produto pela manhã e acompanhamos nosso “bebê” rodando por 
todo o dia. Funcionou perfeitamente. Saímos de lá e fomos jantar em um dos 
melhores lugares da cidade para comemorar. 


Missão cumprida. 


1.2 POR QUE DEVEMOS TESTAR? 


Voltando do jantar, fui direto pra cama, afinal no dia seguinte entenderíamos 
quais seriam as próximas etapas do produto. Mas às 7h da manhã, o telefone 
tocou. Era o responsável pelo posto de gasolina piloto. Ele me ligou justa- 
mente para contar que o posto de gasolina estava completamente parado 
desde as oh: o software parou de funcionar e bloqueou completamente o 
posto de gasolina. 

Nosso software nunca havia sido testado com uma quantidade grande 
de abastecimentos. Os postos em Santo Domingo fazem muitos pequenos 
abastecimentos ao longo do dia (diferente daqui, onde enchemos o tanque 
de uma vez). O sistema não entendeu isso muito bem, e optou por bloquear 
as bombas de gasolina, para evitar fraude, já que não conseguia registrar as 
futuras compras. 

O software fez com que o estabelecimento ficasse 12h parado, sem vender 
nada. Quanto será que isso custou ao dono do estabelecimento? Como será 
que foi a reação dele ao descobrir que o novo produto, no primeiro dia, causou 
tamanho estrago? 

Os Estados Unidos estimam que bugs de software lhes custam aproxi- 
madamente 60 bilhões de dólares por ano [38]. O dinheiro que poderia estar 
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sendo usado para erradicar a fome do planeta está sendo gasto em correções 
de software que não funcionam. 

É incrível a quantidade de software que não funciona. Pergunte ao seu 
amigo não técnico se ele já ficou irritado porque algum programa do seu dia a 
dia simplesmente parou de funcionar. Alguns bugs de software são inclusive 
famosos por todos: o foguete Ariane 5 explodiu por um erro de software; 
um hospital panamenho matou pacientes pois seu software para dosagem de 
remédios errou. 


1.3 POR QUE NÃO TESTAMOS? 


Não há um desenvolvedor que não saiba que a solução para o problema é 
testar seus códigos. A pergunta é: por que não testamos? 

Não testamos porque testar sai caro. Imagine o sistema em que você tra- 
balha hoje. Se uma pessoa precisasse testá-lo do começo ao fim, quanto tempo 
ela levaria? Semanas? Meses? Pagar um mês de uma pessoa a cada mudança 
feita no código (sim, os desenvolvedores também sabem que uma mudança 
em um trecho pode gerar problemas em outro) é simplesmente impossível. 

Testar sai caro, no fim, porque estamos pagando “a pessoa” errada para 
fazer o trabalho. Acho muito interessante a quantidade de tempo que gasta- 
mos criando soluções tecnológicas para resolver problemas “dos outros”. Por 
que não escrevemos programas que resolvam também os nossos problemas? 


1.4 TESTES AUTOMATIZADOS E TDD 


Uma maneira para conseguir testar o sistema todo de maneira constante e 
contínua a um preço justo é automatizando os testes. Ou seja, escrevendo um 
programa que testa o seu programa. Esse programa invocaria os comporta- 
mentos do seu sistema e garantiria que a saída é sempre a esperada. 

Se isso fosse realmente viável, teríamos diversas vantagens. O teste exe- 
cutaria muito rápido (afinal, é uma máquina!). Se ele executa rápido, logo o 
rodaríamos constantemente. Se os rodarmos o tempo todo, descobriríamos 
os problemas mais cedo, diminuindo o custo que o bug geraria. 


Um ponto que é sempre levantado em qualquer discussão sobre testes 
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manuais versus testes automatizados é produtividade. O argumento mais co- 
mum é o de que agora a equipe de desenvolvimento gastará tempo escrevendo 
código de teste; antes ela só gastava tempo escrevendo código de produção. 
Portanto, essa equipe será menos produtiva. 

A resposta para essa pergunta é: o que é produtividade? Se produtividade 
for medida através do número de linhas de código de produção escritos por 
dia, talvez o desenvolvedor seja sim menos produtivo. Agora, se produtivi- 
dade for a quantidade de linhas de código de produção sem defeitos escritos 
por dia, provavelmente o desenvolvedor será mais produtivo ao usar testes 
automatizados. 

Além disso, se analisarmos o dia a dia de um desenvolvedor que faz testes 
manuais, podemos perceber a quantidade de tempo que ele gasta com teste. 
Geralmente ele executa testes enquanto desenvolve o algoritmo completo. Ele 
escreve um pouco, roda o programa, e o programa falha. Nesse momento, 
o desenvolvedor entende o problema, corrige-o, e em seguida executa no- 
vamente o mesmo teste. Quantas vezes por dia ele executa o mesmo teste 
manual? O desenvolvedor que automatiza seus testes perde tempo apenas 1 
vez com ele; nas próximas, ele simplesmente aperta um botão e vê a máquina 
executando o teste pra ele, de forma correta e rápida. 


1.5 CONCLUSÃO 


Minha família inteira é da área médica. Um jantar de fim de semana em casa 
parece mais um daqueles episódios de seriados médicos da televisão: pessoas 
discutindo casos e como resolvê-los. Apesar de entender praticamente nada 
sobre medicina, uma coisa me chama muito a atenção: o fanatismo deles por 
qualidade. 

Um médico, ao longo de uma cirurgia, nunca abre mão de qualidade. Se o 
paciente falar para ele: “Doutor, o senhor poderia não lavar a mão e terminar 
a cirurgia 15 minutos mais cedo?”, tenho certeza de que o médico negaria na 
hora. Ele saberia que chegaria ao resultado final mais rápido, mas a chance 
de um problema é tão grande, que simplesmente não valeria a pena. 

Em nossa área, vejo justamente o contrário. Qual desenvolvedor nunca 
escreveu um código de má qualidade de maneira consciente? Quem nunca 
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escreveu uma “gambiarra"? Quem nunca colocou software em produção sem 
executar o mínimo suficiente de testes para tal? 

Não há desculpas para não testar software. E a solução para que seus testes 
sejam sustentáveis é automatizando. Testar é divertido, aumenta a qualidade 
do seu produto, e pode ainda ajudá-lo a identificar trechos de código que 
foram mal escritos ou projetados (aqui entra a prática de TDD). É muita van- 
tagem. 

Ao longo do livro, espero convencê-lo de que testar é importante, e que 
na verdade é mais fácil do que parece. 


1.6 COMO TIRAR DÚVIDAS? 


Para facilitar a comunicação entre os leitores deste livro e interessados no as- 
sunto, criei um grupo de discussão no Google Groups. Você pode se cadastrar 
em https://groups.google.com/forum/g!forum/tdd-no-mundo-real. 

Toda e qualquer discussão, dúvida ou sugestão será bem-vinda. 

Não se esqueça também de participar do GUJ, o maior portal de desen- 
volvedores do Brasil: http://www.guj.com.br/ 

Lá você pode perguntar, responder, editar e dar pontos às dúvidas e re- 
spostas de outros desenvolvedores. 


CAPITULO 2 


Testes de unidade 


2.1 O QUE É UM TESTE DE UNIDADE? 


Imagine-se passeando em uma loja virtual qualquer na web. Ao selecionar 
um produto, o sistema coloca-o no seu carrinho de compras. Ao finalizar a 
compra, o sistema fala com a operadora de cartão de crédito, retira o pro- 
duto do estoque, dispara um evento para que a equipe de logística separe os 
produtos comprados e lhe envia um e-mail confirmando a compra. 

O software que toma conta de tudo isso é complexo. Ele contém regras de 
negócio relacionadas ao carrinho de compras, ao pagamento, ao fechamento 
da compra. Mas, muito provavelmente, todo esse código não está implemen- 
tado em apenas um único arquivo; esse sistema é composto por diversas pe- 
quenas classes, cada uma com sua tarefa específica. 

Desenvolvedores, quando pensam em teste de software, geralmente imag- 
inam um teste que cobre o sistema como um todo. Um teste de unidade não 
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se preocupa com todo o sistema; ele está interessado apenas em saber se uma 
pequena parte do sistema funciona. 

Um teste de unidade testa uma única unidade do nosso sistema. Geral- 
mente, em sistemas orientados a objetos, essa unidade é a classe. Em nosso 
sistema de exemplo, muito provavelmente existem classes como “Carrin- 
hoDeCompras”, “Pedido”, e assim por diante. A ideia é termos baterias de 
testes de unidade separadas para cada uma dessas classes; cada bateria pre- 


ocupada apenas com a sua classe. 


2.2 PRECISO MESMO ESCREVE-LOS? 


Essa mesma loja virtual precisa encontrar, dentro do seu carrinho de com- 
pras, os produtos de maior e menor valor. Um possível algoritmo para esse 
problema seria percorrer a lista de produtos no carrinho, comparar um a um, 
e guardar sempre a referência para o menor e o maior produto encontrado 
até então. 


Em código, uma possível implementação seria: 


class MaiorEMenor 
private $menor; 
private $maior; 


public function encontra(CarrinhoDeCompras $carrinho) 
{ 
foreach ($carrinho->getProdutos() as $produto) { 
if (empty ($this->menor) 
|| $produto->getValor() < $this->menor->getValor()) { 


$this->menor = $produto; 
} else if (empty($this->maior) 


|| $produto->getValor() > $this->maior->getValor()) { 


$this->maior = $produto; 
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public function getMenor() 
{ 


return $this->menor; 


public function getMaior() 
{ 


return $this->maior; 


Veja o método encontra (). Ele recebe um CarrinhoDeCompras e 
percorre a lista de produtos, comparando sempre o produto corrente com o 
“menor e maior de todos”. Ao final, temos no atributo maior e menor os 
produtos desejados. A figura a seguir mostra como o algoritmo funciona: 


Carrinho de 
compras 





Para exemplificar o uso dessa classe, veja o seguinte código: 
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class TestaMaiorEMenor 

{ 
public function realizaTeste() 
{ 


$carrinho = new CarrinhoDeCompras () ; 


$carrinho->adiciona( 

new Produto ("Liquidificador'", 250.00)); 
$carrinho->adiciona( 

new Produto("Geladeira", 450.00)); 
$carrinho->adiciona( 

new Produto("Jogo de pratos", 70.00)); 


$maiorEMenor = new MaiorEMenor () ; 
$maiorEMenor->encontra($carrinho) ; 


echo "0 menor produto: "; 
echo $maiorEMenor->getMenor()->getNome() . PHP_EOL; 
echo "0 maior produto: "; 
echo $maiorEMenor->getMaior()->getNome() . PHP_EOL; 


O carrinho contém trés produtos: liquidificador, geladeira e jogo de 
pratos. É fácil perceber que o jogo de pratos é o produto mais barato (R$ 
70,00), enquanto que a geladeira é o mais caro (R$ 450,00). A saída do pro- 
grama é exatamente igual à esperada: 


O menor produto: Jogo de pratos 
O maior produto: Geladeira 


Apesar de aparentemente funcionar, se esse código for para produção, a 
loja virtual terá problemas. 


2.3 O PRIMEIRO TESTE DE UNIDADE 





A classe MaiorEMenor respondeu corretamente ao teste anterior, mas ainda 
não é possível dizer se ela realmente funciona para outros cenários. Observe 
o código a seguir: 
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class TestaMaiorEMenor 

{ 
public function realizaTeste() 
{ 


$carrinho = new CarrinhoDeCompras() ; 


$carrinho->adiciona( 

new Produto("Geladeira", 450.00)); 
$carrinho->adiciona( 

new Produto ("Liquidificador'!, 250.00)); 
$carrinho->adiciona( 

new Produto("Jogo de Pratos", 70.00)); 


$maiorEMenor = new MaiorEMenor () ; 
$maiorEMenor->encontra($carrinho) ; 


echo "0 menor produto: "; 
echo $maiorEMenor->getMenor()->getNome() . PHP_EOL; 
echo "0 maior produto: "; 
echo $maiorEMenor->getMaior()->getNome() . PHP_EOL; 


Esse código nao é tão diferente do anterior. Os produtos, bem como os 
valores, são os mesmos; apenas a ordem em que eles são inseridos no carrinho 
foi trocada. Espera-se então que o programa produza a mesma saída. Mas, ao 
executá-lo, a seguinte saída é gerada: 


O menor produto: Jogo de Pratos 

PHP Fatal error: Call to a member function getNome() 

on a non-object in [...]index.php on line 44 

PHP Stack trace: 

PHP 1. {main}() [...]index.php:0 

PHP 2. TestaMaiorEMenor->realizaTeste() [...]index.php:48 
) 


Problema! Essa não era a saída esperada! Agora está claro que a classe 





MaiorEMenor não funciona bem para todos os cenários. Se os produtos, 
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por algum motivo, forem adicionados no carrinho em ordem decrescente, a 
classe nao consegue calcular corretamente. 

Uma pergunta importante para o momento é: será que o desenvolvedor, 
ao escrever a classe, perceberia esse bug? Será que ele faria todos os testes 
necessários para garantir que a classe realmente funcione? 

Como discutido no capítulo anterior, equipes de software tendem a não 
testar software, pois o teste leva tempo e, por consequência, dinheiro. Na 
prática, equipes acabam por executar poucos testes ralos, que garantem ape- 
nas o cenário feliz e mais comum. Todos os problemas da falta de testes, que 
já foram discutidos anteriormente, agora fazem sentido. Imagine se a loja vir- 
tual colocasse esse código em produção. Quantas compras seriam perdidas 
por causa desse problema? 

Para diminuir a quantidade de bugs levados para o ambiente de produção, 
é necessário testar o código constantemente. Idealmente, a cada alteração 
feita, todo o sistema deve ser testado por inteiro novamente. Mas isso deve 
ser feito de maneira sustentável: é impraticável pedir para que seres humanos 
testem o sistema inteiro a cada alteração feita por um desenvolvedor. 

A solução para o problema é fazer com que a máquina teste o software. 
A máquina executará o teste rapidamente e sem custo, e o desenvolvedor não 
gastaria mais tempo executando testes manuais, mas sim apenas em evoluir 
o sistema. 

Escrever um teste automatizado não é tarefa tão árdua. Ele, na verdade, 
se parece muito com um teste manual. Imagine um desenvolvedor que deva 
testar o comportamento do carrinho de compras da loja virtual quando ex- 
istem dois produtos lá cadastrados: primeiramente, ele “clicaria em comprar 
em dois produtos”, em seguida “iria para o carrinho de compras”, e por fim, 
verificaria “a quantidade de itens no carrinho (deve ser 2)” e o “o valor total do 
carrinho (que deve ser a soma dos dois produtos adicionados anteriormente)”. 

Ou seja, de forma generalizada, o desenvolvedor primeiro pensa em um 
cenário (dois produtos comprados), depois executa uma ação (vai ao carrinho 
de compras), e por fim, valida a saída (vê a quantidade de itens e o valor total 
do carrinho). A figura a seguir mostra os passos que um testador geralmente 
faz quando deseja testar uma funcionalidade. 
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Um teste automatizado é similar. Ele descreve um cenário, executa uma 
ação e valida uma saída. A diferença é que quem fará tudo isso será a máquina, 
sem qualquer intervenção humana. 

De certa forma, um teste automatizado já foi escrito neste capítulo. Veja o 
código adiante, escrito para testar superficialmente a classe MaiorEMenor: 


class TestaMaiorEMenor 


{ 


public function realizaTeste() 


{ 


$carrinho = new CarrinhoDeCompras () ; 


$carrinho->adiciona( 

new Produto ("Liquidificador', 250.00)); 
$carrinho->adiciona( 

new Produto("Geladeira", 450.00)); 
$carrinho->adiciona( 

new Produto("Jogo de pratos", 70.00)); 


$maiorEMenor = new MaiorEMenor () ; 
$maiorEMenor->encontra($carrinho) ; 


echo "0 menor produto: "; 
echo $maiorEMenor->getMenor()->getNome() . PHP_EOL; 
echo "0 maior produto: "; 
echo $maiorEMenor->getMaior()->getNome() . PHP_EOL; 


Veja que esse codigo contém, de forma automatizada, boa parte do que 
foi descrito em relação ao teste manual: ele monta um cenário (um car- 
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rinho de compras com 3 produtos), executa uma ação (invoca o método 
encontra ()), e valida a saída (imprime o maior e o menor produto). 

E o melhor: uma máquina faz (quase) tudo isso. Ao rodar o código ante- 
rior, a máquina monta o cenário e executa a ação sem qualquer intervenção 
humana. Mas uma ação humana ainda é requerida para descobrir se o com- 
portamento executou de acordo. Um humano precisa ver a saída e conferir 
com o resultado esperado. 

É preciso que o próprio teste faça a validação e informe o desenvolvedor 
caso o resultado não seja o esperado. Para melhorar esse código, agora só in- 
troduzindo um framework de teste automatizado. Esse framework nos daria 
um relatório mais detalhado dos testes que foram executados com sucesso e, 
mais importante, dos testes que falharam, trazendo o nome do teste e a linha 
que apresentaram problemas. 

Neste livro, faremos uso do PHPUnit [2], o framework de testes de 
unidade mais popular do mundo PHP. 

Precisaremos instalar o PHPUnit pois ele não vem por padrão com o PHP, 
utilizaremos o Composer [32] para esta instalação. 

O Composer, de forma simplificada, é um gerenciador de dependências 
para o PHP e pode ser baixado em https://getcomposer.org/download. Para 
mais detalhes, sugiro ler a documentação oficial no próprio site do Composer. 

Após realizado o download em sua máquina, certifique-se de que em seu 
diretório de trabalho atual existe um arquivo chamado composer .phar. 

Antes mesmo de realizarmos a instalação, definiremos o Autoload de 
nossa aplicação. O Autoload encarrega-se de localizar corretamente as classes 
utilizando namespaces para isso. Utilizaremos a recomendação PSR-4 [22], 
que foi sugerida e aceita pela FIG [21], que é um grupo que reúne os mais di- 
versos Frameworks, CMSs e ferramentas a fim de sugerir padrões para a inter- 
operabilidade entre eles, e indiretamente melhorar os padrões de desenvolvi- 
mento em PHP. Basicamente, o Autoload seguindo a PSR-4 torna-se semel- 
hante aos namespaces do Java ou C#, com a diferença de que não é nativo 
como nas linguagens citadas. 


Crie um arquivo chamado composer. json com o conteúdo a seguir. 


"require-dev" : { 
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"phpunit/phpunit" : "4.«" 
F; 
"autoload" : { 

"psr-4" : { 

"CDC\\Loja\\" : [ 
"src/CDC/Loja", 
"tests/CDC/Loja" 

1, 

"CDC\\Exemplos\\" : [ 
"src/CDC/Exemplos", 
"tests/CDC/Exemplos" 

] 

} 
} 


De forma simples, o conteúdo que fora apresentado para o arquivo 
composer. json informa quais são as dependências em modo de desen- 
volvimento, require-dev, e também informamos qual é o namespace raiz 
e sua localização através de autoload. Todos os exemplos deste livro es- 
tão em repositório no Github, o que facilita o acompanhamento da evolução 
dos testes. Por seguir a recomendação da PSR-4, fez-se necessário adicionar o 
vendor name, que neste caso é CDC (abreviação de Casa do Código) e, em 
seguida, definidos os namespaces deste vendor que serão utilizados: Loja e 





Exemplos. 

As dependências de nossa aplicação para o ambiente de produção são 
declaradas no Composer através do atributo require. Perceba que adi- 
cionamos o sufixo -dev, que caracteriza uso somente em ambiente de desen- 
volvimento. Qualquer dependência que seja crucial para o correto funciona- 
mento do código de produção deve ser adicionada no atributo require e 
não no require-dev. 

Com isso, temos em nosso diretório de trabalho os seguintes ar- 
quivos: composer.phar e composer.json. Antes de mais nada, é 
necessário atualizar o composer.phar e para isso basta executar o co- 
mando php composer.phar self-update. Agora é o momento de re- 
alizar a instalação do PHPUnit. Execute em seu terminal o comando php 
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composer.phar install. O resultado deve ser semelhante ao exibido a 
seguir. 


$ php composer.phar install 
Loading composer repositories with package information 
Installing dependencies (including require-dev) 
- Installing sebastian/version (1.0.3) 
Downloading: 100% 


- Installing sebastian/exporter (1.0.1) 
Downloading: 100% 


- Installing sebastian/environment (1.0.0) 
Downloading: 100% 


- Installing sebastian/diff (1.1.0) 
Downloading: 100% 


- Installing symfony/yaml (v2.4.2) 
Downloading: 100% 


- Installing phpunit/php-text-template (1.2.0) 
Downloading: 100% 


- Installing phpunit/phpunit-mock-objects (2.0.4) 
Downloading: 100% 


- Installing phpunit/php-timer (1.0.5) 
Downloading: 100% 


- Installing phpunit/php-token-stream (1.2.2) 
Downloading: 100% 


- Installing phpunit/php-file-iterator (1.3.4) 
Downloading: 100% 


- Installing phpunit/php-code-coverage (2.0.4) 
Downloading: 100% 
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- Installing phpunit/phpunit (4.0.13) 
Downloading: 100% 


phpunit/phpunit suggests installing phpunit/php-invoker (71.1) 
Writing lock file 
Generating autoload files 


O Composer, bem como o PHPUnit, já estão instalados em nosso projeto. 
Podemos agora criar a estrutura de pastas para iniciarmos a escrita dos testes. 
Definimos no arquivo composer. json que os nossos namespaces seriam 





CDCNLoja e CDC\Exemplos que estariam dentro de src/CDC/Loja e 





src/CDC/Exemplos, respectivamente. Com isto definido, faz-se necessária 
a criação do diretório src, dentro do qual criaremos um novo diretório, 





chamado CDC, e dentro deste, dois novos diretórios, Exemplos e Loja. Da 
mesma forma faremos para a estrutura de testes, com uma pequena diferença: 
a raiz dos testes encontra-se no diretório tests. Dentro dele, um diretório 





chamado CDC e dentro deste, por sua vez, dois novos diretórios, Exemplos 
e Loja. Dentro do namespace Loja criaremos dois diretórios, Produto 
e Carrinho, tanto na estrutura de produção (src/CDC/Loja) como na es- 
trutura de testes (tests/CDC/Loja), visto que ambos compartilham o mesmo 
namespace. Desta forma, separaremos as responsabilidades de cada uma das 
pequenas funcionalidades que a loja possuirá. Para que fique fácil o entendi- 
mento, segue a estrutura de sua aplicação neste momento. 
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vB src 
»— coc 
>- Exemplos 
” EE oja 
> EE carrinho 
> EE Produto 
v EB tests 
“EE coc 
> ES Exemplos 
“E Loja 
>- EB carrinho 
> EE Produto 


> empty 


> EE vendor 


txt) composerjson 
‘tt! composer.lock 


lap composer,phar 


Como é perceptível, a estrutura interna de src e tests é a mesma, 
apenas diferenciando suas responsabilidades, pois em src serão criadas as 
classes de produção, o código final de sua aplicação, enquanto em tests 
serão criadas as classes que irão testar nossa aplicação passo a passo. Também 
foi possível notar que, após a instalação utilizando o Composer, foi criado 
um novo arquivo chamado composer. lock, que basicamente contém de 
forma descrita um espelho de tudo que sua aplicação está utilizando através 
do gerenciador e seus status atuais. Caso uma nova dependência seja adi- 
cionada ou uma existente seja removida do arquivo composer. json, ou 
ainda, se uma destas dependências sofrer atualização por parte dos mantene- 
dores, o Composer compara os arquivos composer. json e o repositório 
onde cada um dos pacotes está disposto. Existindo qualquer alteração, o 
próprio Composer encarrega-se de adicionar, remover ou atualizar. 
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POR QUE UTILIZAR A PSR-4? 


Uma das maiores vantagens de se utilizar a PSR-4 é o fato de você 
poder integrar sua solução dentro dos principais frameworks PHP de 
mercado. A proposta é padronizar o carregamento das classes utilizando, 
para isso, namespaces. Como sua aplicação seguirá um padrão de mer- 
cado, pode ser facilmente portada para praticamente qualquer frame- 
work moderno em forma de módulo (Zend Framework 2), bundle (Sym- 
fony) ou mesmo como uma biblioteca do Composer. Tudo isto com 
muito pouco ou até mesmo nenhum ajuste adicional. 

No início deste livro, a recomendação de autoloader para o PHP 
seguindo as recomendações da FIG era a PSR-o, no entanto, no dia 
07/10/2014 ela se tornou obsoleta, dando preferência à PSR-4. Com isso, 
todos os códigos já existentes no livro à época foram reescritos seguindo 
a nova recomendação. 











Os códigos deste livro não serão baseados em nenhuma IDE e os testes 
serão todos realizados a partir do terminal do Sistema Operacional. 





POR QUE NÃO UTILIZAR UMA IDE? 


A intenção de não utilizar uma IDE em específico é para que o acom- 
panhamento dos exemplos deste livro seja simplificado e que não fique- 
mos presos a uma configuração ou forma de trabalhar, visto que exis- 
tem excelentes ferramentas disponíveis para o desenvolvimento em PHP, 
cada qual com suas particularidades. 











Para que os testes criados sejam executados, é necessário entrar no di- 
retório de trabalho do projeto atual e rodar o seguinte comando no terminal: 


$ ./vendor/bin/phpunit tests 


Um possível resultado desse comando é o seguinte: 


19 


2.3. O primeiro teste de unidade Casa do Código 





$ ./vendor/bin/phpunit src 
PHPUnit 4.4-g1760c16 by Sebastian Bergmann. 


Time: 282 ms, Memory: 4.00Mb 


OK (38 tests, 58 assertions) 


Com esse exemplo, já é possível visualizar corretamente se os testes pas- 
saram ou não, mas podemos deixar esta visualização ainda mais intuitiva adi- 
cionando coloração nos testes. Para isso, o comando utilizado anteriormente 
deve ser acrescido de um parâmetro, o --colors: 


$ ./vendor/bin/phpunit --colors tests 


O resultado será semelhante à imagem a seguir: 


m source : bash - Konsole 


File Edit View Bookmarks Settings Help 


[andrebian@localhost source]$ ./vendor/bin/phpunit --colors tests/ 
PHPUnit 4.4-g1760c16 by Sebastian Bergmann. 


Time: 281 ms, Memory: 4.00Mb 


[andrebian@localhost sourcelg E 


source : bash 





Sempre que rodarmos nossos testes, os que passarem aparecerão na col- 
oração verde, já os que por algum motivo não passarem aparecerão na col- 
oração vermelha. Os motivos para o teste não passar podem ser código ainda 
não implementado, erro no código de produção, teste ignorado ou teste in- 
completo. Sempre que um erro ocorrer, é possível visualizar no próprio ter- 
minal (shell) qual foi o teste e outros detalhes, como as linhas do teste e da 
classe de produção que causaram tal erro. 
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Antes de sairmos criando testes, precisamos entender algumas definições. 
Toda classe de teste deve possuir o sufixo Test, como por exemplo, 
CadastroUsuarioTest. A classe de teste ainda deve estender direta ou 
indiretamente da classe PHPUnit Framework TestCase. Para que um 
método seja reconhecido como um teste, deve possuir o prefixo test, como 
testValidaSenha, por exemplo. Para que a máquina realize seu papel e 
compare o resultado esperado com o resultado corrente, faz-se necessário 
utilizar os asserts que o PHPUnit nos oferece. O que utilizaremos neste 





primeiro testeé o assertEquals (). 


namespace CDC\Loja\Produto; 
require "./vendor/autoload. php"; 


use CDC\Loja\Carrinho\CarrinhoDeCompras, 
CDC\Loja\Produto\Produto, 
CDC\Loja\Produto\MaiorEMenor; 

use PHPUnit_Framework_TestCase as PHPUnit; 


class MaiorEMenorTest extends PHPUnit 


{ 


public function testOrdemDecrescente() 


{ 


$carrinho = new CarrinhoDeCompras () ; 


$carrinho->adiciona( 

new Produto("Geladeira", 450.00)); 
$carrinho->adiciona( 

new Produto ("Liquidificador', 250.00)); 
$carrinho->adiciona( 

new Produto("Jogo de pratos", 70.00)); 


$maiorMenor = new MaiorEMenor (); 
$maiorMenor->encontra($carrinho) ; 


$this->assertEquals("Jogo de pratos", 
$maiorMenor->getMenor () ->getNome()) ; 
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$this->assertEquals ("Geladeira", 
$maiorMenor->getMaior () ->getNome ()) ; 


Pronto. Esse código é executado pelo PHPUnit. O teste, como bem sabe- 
mos, falhará: 


& 


W source : bash - Konsole 


File Edit View Bookmarks Settings Help 
[andrebian@localhost source]$ ./vendor/bin/phpunit --colors tests/ 


A 
PHPUnit 4.4-g1760c16 by Sebastian Bergmann. 
PHP Fatal error: Call to a member function getNome() on a non-object in /mnt/ARQU 
IVOS/Documents/Casa do Codigo/source/tests/src/Loja/Produto/MaiorEMenorTest.php on 

nw 

y 


k 
b 


line 27 

PHP Stack trace: 

PHP 1. {main}() /mnt/ARQUIVOS/Documents/Casa do Codigo/source/vendor/phpunit/php 
unit/phpunit:0 

PHP 2. PHPUnit TextUI Command: :main() /mnt/ARQUIVOS/Documents/Casa do Codigo/sou 
rce/vendor/phpunit/phpunit/phpunit :54 

PHP 3. PHPUnit TextUI Command->run() /mnt/ARQUIVOS/Documents/Casa do Codigo/sour 
ce/vendor/phpunit/phpunit/src/TextUI /Command. php: 138 

PHP 4. PHPUnit TextUI TestRunner->doRun() /mnt/ARQUIVOS/Documents/Casa do Codigo 
/source/vendor/phpunit/phpunit/src/TextUI/Command.php: 186 

PHP 5. PHPUnit Framework TestSuite->run() /mnt/ARQUIVOS/Documents/Casa do Codigo 
/source/vendor/phpunit/phpunit/src/TextUL/TestRunner.php: 423 

PHP 6. PHPUnit Framework TestSuite->run() /mnt/ARQUIVOS/Documents/Casa do Codigo 
/source/vendor/phpunit/phpunit/src/Framework/TestSuite.php:755 

PHP 7. PHPUnit Framework TestCase->run() /mnt/ARQUIVOS/Documents/Casa do Codigo/ 
source/vendor/phpunit/phpunit/src/Framework/TestSuite.php:755 

PHP 8. PHPUnit Framework TestResult->run() /mnt/ARQUIVOS/Documents/Casa do Codig 
o/source/vendor /phpunit/phpunit/src/Framework/TestCase.php:709 

PHP 9. PHPUnit Framework TestCase->runBare() /mnt/ARQUIVOS/Documents/Casa do Cod 
1go/source/vendor/phpunit/phpunit/src/Framework/TestResuLt.php:643 

PHP 10. PHPUnit_Framework_TestCase->runTest() /mnt/ARQUIVOS/Documents/Casa do Cod 
igo/source/vendor/phpunit/phpunit/src/Framework/TestCase.php:773 

(PHP 11. ReflectionMethod->invokeArgs() /mnt/ARQUIVOS/Documents/Casa do Codigo/sou 
rce/vendor/phpunit/phpunit/src/Framework/TestCase.php:901 

PHP 12. Loja\Produto\MaiorEMenorTest->testOrdemDecrescente() /mnt/ARQUIVOS/Docume 
|nts/Casa do Codigo/source/vendor/phpunit/phpunit/src/Framework/TestCase.php:901 
[andrebian@localhost source]¢ E 











= source : bash j 


Para fazer o teste passar, é necessário inicialmente criar as classes 
CarrinhoDeCompras e Produto, e em seguida corrigir o bug na classe 





MaiorEMenor de produção. 


A estrutura da classe CarrinhDeCompras é a seguinte: 


namespace CDC\Loja\Carrinho; 


use CDC\Loja\Produto\Produto; 
use ArrayObject; 
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class CarrinhoDeCompras 


{ 


private $produtos; 


public function __construct() 


{ 
$this->produtos = new ArrayObject(); 
} 
public function adiciona(Produto $produto) 
{ 
$this->produtos->append ($produto) ; 
return $this; 
} 
public function getProdutos() 
{ 
return $this->produtos; 
} 
public function maiorValor() 
{ 
if (count ($this->getItens()) === 0) É 
return 0; 
} 
$maiorValor = $this->getProdutos() [0]->getValor() ; 
foreach ($this->getProdutos() as $produto) { 
if ($maiorValor < $produto->getValor()) { 
$maiorValor = $produto->getValor() ; 
} 
} 
return $maiorValor; 
E; 
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Já a estrutura da classe Produto é: 


namespace CDC\Loja\Produto; 


class Produto 


{ 
private $nome; 
private $valor; 
public function __construct($nome, $valor) 
{ 
$this->nome = $nome; 
$this->valor = $valor; 
} 
function getNome() 
{ 
return $this->nome; 
} 
function getValor() 
{ 
return $this->valor; 
} 
} 


O que faz o código falhar é justamente a presença do else (ele fazia com 
que o código nunca passasse pelo segundo if, que verificava justamente o 
maior elemento). Ao removê-lo, o teste passa: 


namespace CDC\Loja\Produto; 
use CDC\Loja\Carrinho\CarrinhoDeCompras; 
class MaiorEMenor 


{ 


private $menor; 
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private $maior; 


public function encontra(CarrinhoDeCompras $carrinho) 


{ 
foreach ($carrinho->getProdutos() as $produto) { 


if (empty ($this->menor) 

|| $produto->getValor() < $this->menor->getValor()) { 
$this->menor = $produto; 

F} 

if (empty ($this->maior) 

|| $produto->getValor() > $this->maior->getValor()) { 
$this->maior = $produto; 


} 

} 
} 
public function getMenor() 
{ 

return $this->menor; 
} 
public function getMaior() 
{ 

return $this->maior; 
J 
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Ba source : bash - Konsole os Bs 


File Edit View Bookmarks Settings Help 


[andrebian@localhost source]$ ./vendor/bin/phpunit --colors tests/ 
PHPUnit 4.4-g1760c16 by Sebastian Bergmann. 


Time: 67 ms, Memory: 2.00Mb 


[andrebian@localhost sourcel¢ E 


source : bash 





Repare também no tempo que a maquina levou para executar o teste: 67 
milissegundos. Mais rápido do que qualquer ser humano faria. Isso possi- 
bilita ao desenvolvedor executar esse teste diversas vezes ao longo do seu dia 
de trabalho. 

E o melhor: se algum dia um outro desenvolvedor alterar esse código, 
ele poderá executar a bateria de testes automatizados existente e descobrir se 
a sua alteração fez alguma funcionalidade que já funcionava anteriormente 
parar de funcionar. Isso é conhecido como testes de regressão. Eles garantem 
que o sistema não regrediu. 
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ANICHE DIZ: MEU PRIMEIRO TESTE AUTOMATIZADO 


Há muitos anos atrás, trabalhava em uma pequena consultoria de de- 
senvolvimento de software em São Paulo. E, como em toda consultoria, 
precisávamos anotar nossas horas de trabalho em cada um dos projetos 
da empresa, a fim de cobrar corretamente cada um dos clientes. 

Resolvi, por conta própria, criar um simples projeto para controle de 
horas de trabalho (eu precisava de um motivo para experimentar todas 
as coisas que estava aprendendo naquele momento e, dentre elas, testes 
automatizados). O sistema era bem simples: cadastro de funcionários, 
cadastro de projetos, ligação entre um funcionário e um projeto e cadas- 
tro de horas em um projeto. 

Ao final da implementação, apresentei o sistema ao diretor da em- 
presa. Ele adorou, e me sugeriu a implementação de uma simples regra 
de negócio: se o número total de horas colocadas no projeto ultrapasse 
um determinado limite, nenhum funcionário poderia adicionar mais ho- 
ras nele. 

A implementação era bem trivial: bastava fazer um if. Lembro-me 
que implementei a regra de negócio e então escrevi o teste de unidade 
para garantir que havia implementado corretamente. O teste que acabei 
de escrever ficou verde, mas três ou quatro testes que já existiam ficaram 
vermelhos. A única linha de código que escrevi fez com que funcionali- 
dades que já funcionavam parassem de trabalhar corretamente. 

Naquele momento, vieram-me à cabeça todas as vezes que escrevi 
uma ou duas linhas de código, aparentemente simples, mas que pode- 
riam ter quebrado o sistema. Percebi então a grande vantagem da bateria 
de testes automatizados: segurança. Percebi como é fácil quebrar código, 
e como é difícil perceber isso sem testes automatizados. Daquele dia em 
diante, penso duas vezes antes de escrever código sem teste. 
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2.4 CONTINUANDO A TESTAR 


Ainda são necessários muitos testes para garantir que a classe MaiorEMenor 





funcione corretamente. Até agora, o único cenário testado são produtos em 
ordem decrescente. Muitos outros cenários precisam ser testados. Dentre 
eles: 


e Produtos com valores em ordem crescente; 
e Produtos com valores em ordem variada; 


e Um único produto no carrinho. 





Conhecendo o código da classe MaiorEMenor, é possível prever que 
esses cenários funcionarão corretamente. Escrever testes automatizados para 
eles pode parecer inútil por enquanto. 

Entretanto, é importante lembrar que, em códigos reais, muitos desen- 
volvedores fazem alterações nele. Para o desenvolvedor que implementa a 
classe, o código dela é bem natural e simples de ser entendido. Mas para os 
futuros desenvolvedores que a alterarão, esse código pode não parecer tão 
simples. É necessário prover segurança para eles nesse momento. Portanto, 
apesar de alguns testes parecerem desnecessários nesse instante, eles garan- 
tirão que a evolução dessa classe será feita com qualidade. 

Apenas para exemplificar mais ainda, vamos escrever mais um teste, dessa 
vez para um carrinho com apenas 1 produto. Repare que, neste cenário, é 
esperado que o maior e menor produtos sejam o mesmo: 


public function testApenasUmProduto() 
{ 
$carrinho = new CarrinhoDeCompras() ; 


$carrinho->adiciona(new Produto("Geladeira", 450.00)); 


$maiorEMenor = new MaiorEMenor () ; 
$maiorEMenor->encontra($carrinho) ; 


$this->assertEquals("Geladeira", 
$maiorEMenor->getMenor () ->getNome()) ; 
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$this->assertEquals("Geladeira", 
$maiorEMenor->getMaior () ->getNome()) ; 





COMPARANDO SO O NOME? 


Ao invés de comparar apenas o nome do produto, você 
poderia comparar se o objeto recebido é mesmo um produto: 
Sthis->assertInstance0Of( "CDC\Loja\Produto\Produto", 
$maiorMenor->getMenor ());, por exemplo. Existem ainda 
outras possibilidades para testar se o conteúdo retornado é de fato 
do tipo esperado: Sthis->assertInternalType ("object", 
SmaiorMenor->getMenor ()); 

Em certos casos, essa solução pode ser mais interessante, afinal você 
comparará o objeto de várias maneiras e não apenas um atributo. 











2.5 CONCLUSÃO 


Desenvolvedores gastam toda sua vida automatizando processos de outras 
áreas de negócio, criando sistemas para RHs, controle financeiro, entre out- 
ros, com o intuito de facilitar a vida daqueles profissionais. Por que não criar 
software que automatize o seu próprio ciclo de trabalho? 

Testes automatizados são fundamentais para um desenvolvimento de 
qualidade, e é obrigação de todo desenvolvedor escrevê-los. Sua existência 
traz diversos benefícios para o software, como o aumento da qualidade e a 
diminuição de bugs em produção. Nos próximos capítulos, discutiremos so- 


bre como aumentar ainda mais o feedback que os testes nos dão sobre a qual- 
idade do software. 
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CAPITULO 3 


Introdução ao Test-Driven 
Development 


Desenvolvedores (ou qualquer outro papel que é executado dentro de uma 
equipe de software) estão muito acostumados com o “processo tradicional” 
de desenvolvimento: primeiro a implementação e depois o teste. Entre- 
tanto, uma pergunta interessante é: Será que é possível inverter, ou seja, testar 
primeiro e depois implementar? E mais importante, faz algum sentido? 

Para responder essa pergunta, ao longo deste capítulo desenvolveremos 
um simples algoritmo matemático, mas dessa vez invertendo o ciclo de de- 
senvolvimento: o teste será escrito antes da implementação. Ao final, discu- 
tiremos as vantagens e desvantagens dessa abordagem. 


31. O problema dos números romanos Casa do Código 





3.1 O PROBLEMA DOS NÚMEROS ROMANOS 


Numerais romanos foram criados na Roma Antiga e eles foram utilizados 
em todo o seu império. Os números eram representados por sete diferentes 
símbolos, listados na tabela a seguir. 


e I, unus, 1, (um) 

e V, quinque, 5 (cinco) 

e X, decem, 10 (dez) 

* L, quinquaginta, 50 (cinquenta) 
e C, centum, 100 (cem) 

* D, quingenti, 500 (quinhentos) 


e M, mille, 1.000 (mil) 


Para representar outros números, os romanos combinavam esses símbo- 
los, começando do algarismo de maior valor e seguindo a regra: 


e Algarismos de menor ou igual valor à direita são somados ao algarismo 
de maior valor; 


e Algarismos de menor valor à esquerda são subtraidos do algarismo de 
maior valor. 


Por exemplo, XV representa 15 (10 + 5) e o número XXVIII representa 
28 (10 +10 +5 +1+1+1). Há ainda uma outra regra: nenhum símbolo 
pode ser repetido lado a lado por mais de 3 vezes. Por exemplo, o número 4 é 
representado pelo número IV (5 - 1) e não pelo número III. 

Existem outras regras (especialmente para números maiores, que podem 
ser lidas aqui [37]), mas em linhas gerais, este é o problema a ser resolvido. 
Dado um numeral romano, o programa deve convertê-lo para o número in- 
teiro correspondente. 
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3.2 O PRIMEIRO TESTE 


Conhecendo o problema dos numerais romanos, é possível levantar os difer- 
entes cenários que precisam ser aceitos pelo algoritmo: um símbolo, dois sím- 
bolos iguais, três símbolos iguais, dois símbolos diferentes do maior para o 
menor, quatro símbolos dois a dois, e assim por diante. Dados todos estes 
cenários, uns mais simples que os outros, começaremos pelo mais simples: 
um único símbolo. 

Começando pelo teste “deve entender o símbolo IP A classe 
responsável pela conversão pode ser chamada, por exemplo, de 
ConversorDeNumeroRomano, e o método converte (), recebendo 
uma String com o numeral romano e devolvendo o valor inteiro represen- 


tado por aquele número: 


namespace CDC\Exemplos; 
require "./vendor/autoload. php"; 


use CDC\Exemplos\ConversorDeNumeroRomano; 
use PHPUnit_Framework_TestCase as PHPUnit; 


class ConversorDeNumeroRomanoTest extends PHPUnit 


{ 
public function testDeveEntender0SimboloT() 


{ 
$romano = new ConversorDeNumeroRomano () ; 
$numero = $romano->converte("I") ; 
$this->assertEquals(1, $numero) ; 

} 
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UTILIZAÇÃO DE UM NOVO NAMESPACE 


Como você pôde perceber, continuamos trabalhando com names- 
paces assim como nos exemplos do capítulo anterior. Isto facilita a uti- 
lização do PHPUnit que já se encontra instalado no projeto que ini- 
ciamos anteriormente, não sendo necessárias outras configurações. A 
única diferença é que, em vez de utilizarmos o namespace Loja, agora 





estamos utilizando o namespace Exemplos, pois mesmo que para ex- 
emplificar não faz sentido deixar os testes de números romanos fazendo 
parte da Loja. 











Veja que nesse momento esse código não é executado; a classe 
ConversorDeNumeroRomano, bem como o método converte () não ex- 
istem. Para resolver o erro de interpretação, é necessário criar a classe, mesmo 
que sem uma implementação real: 


namespace CDC\Exemplos; 


class ConversorDeNumeroRomano 


{ 
public function converte ($numeroEmRomano) 
{ 
return 0; 
} 
} 


De volta ao teste, ele agora executa, porém com falha. Mas não há prob- 
lema; isso já era esperado. Para fazê-lo passar, introduziremos ainda uma 
segunda regra: o código escrito deve ser sempre o mais simples possível. 


Com essa regra em mente, o código mais simples que fará o teste passar 
é fazer simplesmente o método converte () retornar o número 1: 


namespace CDC\Exemplos; 


class ConversorDeNumeroRomano 


{ 
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public function converte ($numeroEmRomano) 
{ 


return 1; 


Desenvolvedores, muito provavelmente, não ficarão felizes com essa im- 
plementação, afinal ela funciona apenas para um caso. Mas isso não é prob- 
lema, a implementação não está pronta; ainda estamos trabalhando nela. 

Um próximo cenário seria o símbolo V. Nesse caso, o algoritmo deve re- 
tornar 5. Novamente começando pelo teste: 


public function testeDeveEntender0SimboloV() 


{ 
$romano = new ConversorDeNumeroRomano () ; 
$numero = $romano->converte("V") ; 
$this->assertEquals(5, $numero) ; 

} 


Esse teste também falha. Mais uma vez, faremos a implementação mais 
simples que resolverá o problema. Podemos, por exemplo, fazer com que o 
método converte () verifique o conteúdo do numero a ser convertido: se 
o valor for ‘T’, o método retorna 1; se o valor for “V”, o método retorna 5: 


public function converte ($numeroEmRomano) 


{ 
if ( $numeroEmRomano === "y" ) { 
return 5; 
} 
return 1; 
} 


Os testes passam (os dois que temos da classe 
ConversorDeNumeroRomano e dos demais já criados no capítulo an- 
terior). Poderíamos repetir o mesmo teste e a mesma implementação para 
os símbolos que faltam (X, L, C, M, ...). Mas nesse momento, já temos uma 
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primeira definição sobre nosso algoritmo: quando o numeral romano possui 
apenas um símbolo, basta devolvermos o inteiro associado a ele. 

Em vez de escrever um monte de ifs para cada símbolo, é possível usar 
um switch, que corresponde melhor ao nosso cenário. Melhorando ainda 
mais, em vez do switch, é possível guardar os símbolos em uma tabela, ou 
em um array associativo com chave e valor para o algarismo e o inteiro corre- 
spondente a ele. Sabendo disso, vamos nesse momento alterar o código para 
refletir a solução: 


namespace CDC\Exemplos; 


class ConversorDeNumeroRomano 


{ 
protected $tabela = array( 
"I" => 1, 
ny" => 5, 
"Xx" => 10, 
"L" => 50, 
"c" => 100, 
"D" => 500, 
"M" => 1000 
); 
public function converte ($numeroEmRomano) 
{ 
if ( array_key_exists($numeroEmRomano, $this->tabela) ) { 
return $this->tabela[$numeroEmRomano] ; 
} 
return 0; 
} 
} 


Ambos os testes continuam passando. Passaremos agora para um se- 
gundo cenário: dois símbolos em sequência, como por exemplo, “II” ou “XX”. 
Começando novamente pelo teste, temos: 


public function testeDeveEntender0SimboloII() 
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{ 
$romano = new ConversorDeNumeroRomano () ; 
$numero = $romano->converte("II") ; 
$this->assertEquals(2, $numero) ; 

} 


Para fazer o teste passar de maneira simples, é possível simplesmente adi- 
cionar os símbolos “II” na tabela: 


protected $tabela = array( 


"I" => 1, 
"II" => 2, 
"yn => 5, 
"x" => 10, 
"L" => 50, 
"c" => 100, 
"D" => 500, 
"4" => 1000 


); 


O teste passa. Mas, apesar de simples, essa nao parece uma boa ideia 
de implementação: seria necessário incluir todos os possíveis símbolos nessa 
tabela, o que não faz sentido. 

É hora de refatorar esse código novamente. Uma solução seria iterar em 
cada um dos símbolos no numeral romano e acumular seu valor; ao final, 
retornar o valor acumulado. Para isso, é necessário mudar a tabela para 
guardar somente os símbolos principais da numeração romana. Uma possível 
implementação deste algoritmo seria: 


protected $tabela = array( 


"I" => 1, 
"y" => 5, 
"x" => 10, 
"L" => 50, 
"c" => 100, 
"D" => 500, 
"4" => 1000 


37 


3.2. O primeiro teste Casa do Código 





public function converte ($numeroEmRomano) 


{ 
$acumulador = 0; 
for($i = O; $i < strlen($numeroEmRomano); $i++ ) { 
$numCorrente = $numeroEmRomano [$i] ; 
if ( array_key_exists($numCorrente, $this->tabela) ) 1 
$acumulador += $this->tabela[numCorrente] ; 
} 
} 
return $acumulador; 
} 


Os testes continuam passando. Dessa forma, resolvemos o problema de 
dois símbolos iguais em seguida. O próximo cenário são quatro símbolos, 
dois a dois, como por exemplo, “XXII”, que deve resultar em 22. O teste: 


public function testeDeveEntender0SimboloXXII() 


{ 
$romano = new ConversorDeNumeroRomano () ; 
$numero = $romano->converte("XXII"); 
$this->assertEquals(22, $numero) ; 

} 


Esse teste já passa sem que precisemos fazer qualquer alteração. O algo- 
ritmo existente até aqui já resolve o problema. Vamos então para o próximo 
E 4 . lA c » ce » 2 ~ 
cenário: números como “IV” ou “IX”, nos quais não basta apenas somar os 
símbolos existentes. 


Novamente, começando pelo teste: 


public function testDeveEntender0SimboloIX() 


{ 
$romano = new ConversorDeNumeroRomano () ; 
$numero = $romano->converte("IX") ; 
$this->assertEquals(9, $numero) ; 

} 


Para fazer esse teste passar, é necessário pensar um pouco melhor sobre o 
problema. Repare que os símbolos em um numeral romano, da direita para 
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a esquerda, sempre crescem. 


Quando um número à esquerda é menor do 


que seu vizinho à direita, este número deve então ser subtraído ao invés de 


somado no acumulador. Esse 


algoritmo, em código: 


public function converte ($numeroEmRomano) 


for($i = strlen($numeroEmRomano) - 1; $i >= 0; $i--) { 


// pega o inteiro referente ao simbolo atual 


if ( array_key_exists($numCorrente, $this->tabela) ) 1 
$atual = $this->tabela[$numCorrente] ; 


// se o da direita for menor, o multiplicaremos 


if ($atual < $ultimoVizinhoDaDireita) { 


$acumulador += ($this->tabela[$numCorrente] 


* $multiplicador) ; 


{ 
$acumulador = 0; 
$ultimoVizinhoDaDireita = 0; 
$atual = 0; 
$numCorrente = $numeroEmRomano [$i]; 
} 
// por -1 para torná-lo negativo 
$multiplicador = 1; 
$multiplicador = -1; 
} 
// atualiza o vizinho da direita 
$ultimoVizinhoDaDireita = $atual; 
} 
return $acumulador; 
} 


Os testes agora passam. Mas veja, existe código repetido 


ali. Na linha em que o 


acumulador é somado com o valor atual, 





$this->tabela[$numero 


EmRomano[$i]] pode ser substituído pela 


variável $atual. Melhorando o código, temos: 


$acumulador += ($atual x 


$multiplicador) ; 
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A refatoração foi feita com sucesso, já que os testes continuam passando. 
Ao próximo cenário: numeral romano que contenha tanto números “inver- 
tidos” como “IV”, e dois símbolos lado a lado, como “XX”. Por exemplo, o 
número “XXIV”, que representa o número 24. 


Começando pelo teste: 


public function testDeveEntender0SimboloXXIV() 


{ 
$romano = new ConversorDeNumeroRomano () ; 
$numero = $romano->converte ("XXIV") ; 
$this->assertEquals(24, $numero) ; 

} 


Esse teste já passa; o algoritmo criado até então já atende o cenário do 
teste. Ainda há outros cenários que poderiam ser testados, mas já fizemos o 
suficiente para discutir sobre o assunto. 


3.3 REFLETINDO SOBRE O ASSUNTO 


De maneira mais abstrata, o ciclo que foi repetido ao longo do processo de 
desenvolvimento da classe anterior foi: 


e Escrevemos um teste de unidade para uma nova funcionalidade; 
e Vimos o teste falhar; 
e Implementamos o código mais simples para resolver o problema; 
e Vimos o teste passar; 


e Melhoramos (refatoramos) nosso código quando necessário. 


Esse ciclo de desenvolvimento é conhecido por Test-Driven Develop- 
ment (TDD), ou, Desenvolvimento Guiado pelos Testes. A ideia é simples: 
o desenvolvedor deve começar a implementação pelo teste e deve, o tempo 
todo, fazer de tudo para que seu código fique simples e com qualidade. 
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(1) Escreve o teste mais simples 


sO TD O 





(4) Refatora (2) Vê ele 
para remover falhar 
duplicidade de 
dados e 
de código 





(3) Implementa a solução mais simples 
que resolve o problema 


Esse ciclo é também conhecido como ciclo vermelho-verde-refatora (ou 
red-green-refactor). O primeiro passo é escrever um teste que falha. A cor 
vermelha representa esse teste falhando. Em seguida, fazemo-lo passar (a cor 
verde representa ele passando). Por fim, refatoramos para melhorar o código 
que escrevemos. 


3.4 QUAIS AS VANTAGENS? 


Muitos praticantes de TDD afirmam que executar esse ciclo pode ser muito 
vantajoso para o processo de desenvolvimento. Algumas das vantagens são: 


e Foco no teste e não na implementação. Ao começar pelo teste, o pro- 
gramador consegue pensar somente no que a classe deve fazer, e es- 
quece por um momento da implementação. Isso o ajuda a pensar em 
melhores cenários de teste para a classe sob desenvolvimento. 


e Código nasce testado. Se o programador pratica o ciclo corretamente, 
isso implica que todo o código de produção escrito possui ao menos 
um teste de unidade verificando que ele funciona corretamente. 


* Simplicidade. Ao buscar pelo código mais simples constantemente, 
o desenvolvedor acaba por fugir de soluções complexas, comuns em 
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todos os sistemas. O praticante de TDD escreve código que apenas re- 
solve os problemas que estão representados por um teste de unidade. 
Quantas vezes o desenvolvedor não escreve código desnecessariamente 
complexo? 


e Melhor reflexão sobre o design da classe. No cenário tradicional, 
muitas vezes a falta de coesão ou o excesso de acoplamento são cau- 
sados pelo desenvolvedor que só pensa na implementação e acaba es- 
quecendo como a classe vai funcionar perante o todo. Ao começar pelo 
teste, o desenvolvedor pensa sobre como sua classe deverá se compor- 
tar frente às outras classes do sistema. O teste atua como o primeiro 
cliente da classe que está sendo escrita. Nele, o desenvolvedor toma 
decisões como o nome da classe, os seus métodos, parâmetros, tipos 
de retorno etc. No fim, todas elas são decisões de design e, quando o 
desenvolvedor consegue observar com atenção o código do teste, seu 
design de classes pode crescer muito em qualidade. 


Todos estes pontos serão mais bem descritos e aprofundados no capítulo 
a seguir. Nesse momento, foque nestas vantagens. Uma pergunta que pode 
vir à cabeça é: “No modelo tradicional, em que os testes são escritos depois, o 
desenvolvedor não tem os mesmos benefícios? 

A resposta é sim. Mesmo desenvolvedores que escrevem testes depois po- 
dem obter as mesmas vantagens. Um desenvolvedor pode perceber que está 
com dificuldades de escrever um teste e descobrir que o design da classe que 
implementou tem problemas; ele pode também conseguir abstrair a imple- 
mentação e escrever bons cenários de teste. 

Mas há uma diferença crucial: a quantidade de vezes que um progra- 
mador praticante de TDD recebe feedback sobre esses pontos e a quantidade 
que um programador que não pratica TDD recebe. 

Veja a figura a seguir. O praticante de TDD escreve um pouco de testes, 
um pouco de implementação e recebe feedback. Isso acontece ao longo do 
desenvolvimento de maneira frequente. Já um programador que não pratica 
TDD espera um tempo (às vezes longo demais) para obter o mesmo feedback. 


42 


Casa do Código Capítulo 3. Introdução ao Test-Driven Development 





Feedback dos testes no projeto de classes 


Desenvolvimento 
| Freios 
SS m 

tradicional 


Feedback dos testes no projeto de classes 


Ao receber feedback desde cedo, o programador pode melhorar o código 
e corrigir problemas a um custo menor do que o programador que recebeu a 
mesma mensagem muito tempo depois. Todo programador sabe que alterar 
o código que ele acabou de escrever é muito mais fácil e rápido do que alterar 
o código escrito 3 dias atrás. 

No fim, TDD apenas maximiza a quantidade de feedback sobre o código 
que está sendo produzido, fazendo o programador perceber os problemas an- 
tecipadamente e, por consequência, diminuindo os custos de manutenção e 
melhorando o código. 
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DESENVOLVEDORES E A BUSCA PELA COMPLEXIDADE 


Acho impressionante como nós desenvolvedores somos atraídos por 
complexidade. Gostamos de problemas difíceis, que nos desafiem. 
Lembro-me que no começo de carreira, quando pegava alguma fun- 
cionalidade simples de ser implementada, eu mesmo “aumentava a fun- 
cionalidade” somente para torná-la interessante do ponto de vista téc- 
nico. Ou seja, um simples relatório se tornava um relatório complexo, 
com diversos filtros e que podia ser exportado para muitos formatos 
diferentes. 

Aprender a ser simples foi difícil. O TDD, de certa forma, me aju- 
dou nisso. Ao pensar de pouco em pouco, e implementar somente o 
necessário para resolver o problema naquele momento, comecei a perce- 
ber que poderia gastar meu tempo implementando funcionalidades que 
realmente agregariam valor para o usuário final. 

Portanto, não ache que “ser simples” é fácil. Lembre-se que somos 
atraídos por complexidade. 











3.5 UM POUCO DA HISTÓRIA DE TDD 


TDD ficou bastante popular após a publicação do livro TDD: By Example, 
do Kent Beck, em 2002. O próprio Kent afirma que TDD não foi uma ideia 
totalmente original. Ele conta que, em algum momento de sua vida, leu em 
algum dos livros de seu pai (que também era programador) sobre uma técnica 
de testes mais antiga, com a qual o programador colocava na fita o valor que 
ele esperava daquele programa, e então o desenvolvia até chegar naquele valor. 

Ele próprio conta que achou a ideia estúpida. Qual o sentido de escrever 
um teste que falha? Mas resolveu experimentar. Após a experiência, ele disse 
que “as pessoas sempre falavam para ele conseguir separar o que o programa 
deve fazer, da sua implementação final, mas que ele não sabia como fazer, até 
aquele momento em que resolveu escrever o teste antes” 

Daquele momento em diante, Kent Beck continuou a trabalhar na ideia. 
Em 1994, ele escreveu o seu primeiro framework de testes de unidade, o SUnit 
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(para Smalltalk). Em 1995, ele apresentou TDD pela primeira vez na OOPSLA 
(conferência muito famosa da área de computação, já que muitas novidades 
tendem a aparecer lá). 

Já em 2000, o JUnit surgiu e Kent Beck, junto com Erich Gamma, publi- 
cou o artigo chamado de “Test Infected” [1], que mostrava as vantagens de se 
ter testes automatizados e como isso pode ser viciante. 

Finalmente em 2002, Kent Beck lançou seu livro sobre isso, e desde então 
a prática tem se tornado cada vez mais popular entre os desenvolvedores. 

A história mais completa pode ser vista na Wiki da C2 [3] ou na palestra 
do Steve Freeman e Michael Feathers na QCON de 2009 [17]. 





FERREIRA FALA 


Duas histórias muito conhecidas cercam Kent Beck e o nascimento 
dos primeiros frameworks de testes unitários. O SUnit, para Smalltalk, 
não era um código distribuído em arquivos da maneira usual. Beck na 
época atuava como consultor e tinha o hábito de recriar o framework 
junto com os programadores de cada cliente. A criação do JUnit tam- 
bém é legendária: a primeira versão foi desenvolvida em uma sessão de 
programação pareada entre o Kent Beck e o Erich Gamma em um voo 
Zurique-Atlanta. 











3.6 CONCLUSÃO 


Neste capítulo, apresentamos TDD e mostramos algumas das vantagens que 
o programador obtém ao utilizá-la no seu dia a dia. Entretanto, é possível 
melhorar ainda mais a maneira na qual o programador faz uso da prática. 

Somente praticando TDD com esse simples exemplo, é possível levantar 
diversas questões, como: 


e Muitos cenários foram deixados para trás, como por exemplo, a con- 


versão de números como “CC”, “MM” etc. Eles devem ser escritos? 


e O inverso da pergunta anterior: testes para ‘T, “V’, “X” devem ser con- 
siderados diferentes ou repetidos? 
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e E quanto à repetição de código dentro de cada teste? É possível melho- 
rar a qualidade de código do próprio teste? 


e A ideia de sempre fazer o teste passar da maneira mais simples possível 
faz sentido? Deve ser aplicada 100% do tempo? 


e Existe alguma regra para dar nomes aos testes? 
e Qual o momento ideal para refatorar o código? 


e Se durante a implementação, um teste antigo, que passava, quebra, o 
que devo fazer? 


Para que um desenvolvedor faça uso de TDD de maneira profissional e 
produtiva, estes e outros pontos devem ser discutidos e clarificados. Nos 
próximos capítulos, responderemos cada uma dessas perguntas, usando 
como exemplo um sistema razoavelmente complexo muito similar aos en- 
contrados no mundo real. 
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Simplicidade e Baby Steps 


No capitulo anterior, apresentamos TDD em um exemplo complexo do ponto 
de vista algoritmico, mas bem controlado. Mesmo assim, ele foi muito util e 
serviu para mostrar os passos de um desenvolvedor que pratica TDD. 

O mundo real é mais complexo do que isso; algoritmos matemáticos são 
combinados e interagem com entidades que vêm do banco de dados e são ap- 
resentados para o usuário através de alguma interface. De agora em diante, 
os exemplos a serem trabalhados serão outros e, com certeza, mais parecidos 
com a realidade. No mundo real, as coisas evoluem e mudam rapidamente. 
Portanto, nos próximos exemplos, sempre imagine que eles ficarão mais com- 


plexos e evoluirão. 
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4.1 O PROBLEMA DO CÁLCULO DE SALÁRIO 


Suponha que uma empresa precise calcular o salário do funcionário e seus de- 
scontos. Para calcular esse desconto, a empresa leva em consideração o salário 
atual e o cargo do funcionário. Vamos representar funcionários e cargos da 
seguinte maneira: 


namespace CDC\Loja\RH; 


class Funcionario 


1 


protected $nome; 
protected $salario; 
protected $cargo; 


public function 


{ 


_construct ($nome, $salario, $cargo) 


$this->nome = $nome; 
$this->salario = $salario; 
$this->cargo = $cargo; 


public function getNome() 
{ 


return $this->nome; 


public function getSalario() 
{ 


return $this->salario; 


public function getCargo() 
{ 


return $this->cargo; 
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Repare que um funcionário possui nome, salário e cargo. Também é pos- 
sível perceber que novamente reutilizamos o projeto criado nos capítulos an- 
teriores, apenas alocando a classe Funcionario em um namespace respon- 
sável por tratar de questões de Recursos Humanos, logo, RH. 


As regras de negócio são as seguintes: 


e Desenvolvedores possuem 20% de desconto caso seus salários sejam 
maiores do que R$ 3000,0. Caso contrário, o desconto é de 10%. 


e DBAs e testadores possuem desconto de 25% se seus salários forem 
maiores do que R$ 2500,0. 15%, em caso contrário. 


Mapearemos também os cargos em uma classe específica para que, sem- 
pre que um novo cargo se tornar necessário, ele seja facilmente registrado em 
um local apenas. 


namespace CDC\Loja\RH; 


class TabelaCargos 


{ 
const DESENVOLVEDOR = 1; 
const DBA = 2; 
const TESTADOR = 3; 

} 


4.2 IMPLEMENTANDO DA MANEIRA MAIS SIMPLES 
POSSÍVEL 


É hora de implementar essas regras. Uma primeira ideia é criar uma 
classe CalculadoraDeSalario, que recebe um Funcionario e retorna 
o salário do funcionário com o desconto já subtraído. 

O primeiro cenário a ser testado será o de desenvolvedores com salários 
menor do que R$3000,00. Sabemos que o desconto é de 10%. Portanto, se o 
desenvolvedor ganhar R$1500,00, seu salário menos desconto deve ser de R$ 
1350,00 (1500 * 90%): 
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namespace CDC\Loja\RH; 

require "./vendor/autoload.php"; 

use PHPUnit Framework TestCase as PHPUnit; 

use CDC\Loja\RH\CalculadoraDeSalario, 
CDC\Loja\RH\Funcionario, 


CDC\Loja\RH\TabelaCargos; 


class CalculadoraDeSalarioTest extends PHPUnit 


{ 
public function 
testCalculoSalarioDesenvolvedoresComSalarioAbaixoDoLimite() 
{ 
$calculadora = new CalculadoraDeSalario(); 
$desenvolvedor = new Funcionario( 

"Andre", 1500.0, TabelaCargos: : DESENVOLVEDOR) ; 
$salario = $calculadora->calculaSalario($desenvolvedor) ; 
$this->assertEquals(1500.0 * 0.9, 

$salario, null, 0.00001); 

} 
} 


Hora de fazer o teste passar. Mas lembre-se que a ideia é fazer o teste 
passar da maneira mais simples possível. Veja o código a seguir: 


namespace CDC\Loja\RH; 


use Loja\RH\Funcionario; 


class CalculadoraDeSalario 


{ 


public function calculaSalario(Funcionario $funcionario) 


{ 
return 1350.0; 
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É possível ser mais simples do que isso? O código retorna diretamente o 
valor esperado pelo teste! Isso é aceitável, pois o código ainda não está final- 
izado. 

Vamos agora ao próximo cenário: desenvolvedores que ganham mais do 
que R$ 3000,00. O teste é bem similar ao anterior: 


public function 
testCalculoSalarioDesenvolvedoresComSalarioAcimaDoLimite() 


{ 
$calculadora = new CalculadoraDeSalario(); 
$desenvolvedor = new Funcionario( 

"Andre", 4000.0, TabelaCargos: :DESENVOLVEDOR) ; 
$salario = $calculadora->calculaSalario($desenvolvedor) ; 
$this->assertEquals(4000.0 * 0.8, $salario, null, 0.00001); 

} 
Novamente, fazemos o teste passar da maneira mais simples possível. Veja 
o código: 


public function calculaSalario(Funcionario $funcionario) 


{ 
if ( $funcionario->getSalario() > 3000 ) { 
return 3200.0; 


} 

return 1350.0; 
} 

Um simples if verifica o salário do funcionário e retorna os valores esper- 
ados. 


O próximo teste agora garante que DBAs com salários inferiores a 
R$1500,00 recebam 15% de desconto: 
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public function 
testDeveCalcularSalarioParaDBAsComSalarioAbaixoDoLimite() 


{ 
$calculadora = new CalculadoraDeSalario(); 
$dba = new Funcionario("Andre", 500.0, TabelaCargos: :DBA) ; 
$salario = $calculadora->calculaSalario($dba) ; 
$this->assertEquals(500.0 * 0.85, $salario, null, 0.00001); 
} 


Para fazer esse teste passar da maneira mais simples, basta novamente 
colocar um outro if: 


public function calculaSalario(Funcionario $funcionario) 
{ 
if ( $funcionario->getCargo() 
=== TabelaCargos: :DESENVOLVEDOR) { 
if ( $funcionario->getSalario() > 3000 ) 1 
return 3200.0; 
E; 
return 1350.0; 


return 425.0; 


Repare que, se for desenvolvedor, continuamos usando aquele código 
simples que escrevemos. Caso contrário, retornamos 425.0, que é o valor es- 
perado para o salário do DBA. 

Mas, antes de continuarmos, precisamos discutir sobre o processo uti- 
lizado até agora. 


4.3 PASSOS DE BEBÊ (OU BABY STEPS) 


A ideia de sempre tomar o passo mais simples que resolva o problema naquele 
momento (e faça o teste passar) é conhecido pelos praticantes de TDD como 
baby steps. A vantagem desses passos de bebê é tentar levar o desenvolvedor 
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sempre ao código mais simples e, por consequência, mais fácil de ser com- 
preendido e mantido posteriormente. 

O problema é que a ideia dos passos de bebê é muito mal interpretada por 
muitos praticantes. Por exemplo, veja que ao final tínhamos 3 testes, 2 para 
as regras do desenvolvedor e 1 para a regra do DBA, e a implementação final 
gerada até então era: 


public function calculaSalario(Funcionario $funcionario) 
{ 
if ( $funcionario->getCargo() 
=== TabelaCargos::DESENVOLVEDOR) { 
if ( $funcionario->getSalario() > 3000 ) { 
return 3200.0; 
E; 
return 1350.0; 


return 425.0; 


Repare que, a cada teste, nós implementamos a modificação mais sim- 
ples (TDD prega por simplicidade), que era justamente adicionar mais um 
if e colocar o valor fixo que fazia o teste passar. Não há modificação mais 
simples do que essa. 

O problema é que em algum momento fizemos tanto isso que nossa im- 
plementação passou a ficar muito longe da solução ideal. Veja que, dada a 
implementação atual, levá-la para a solução flexível que resolverá o problema 
de forma correta não será fácil. O código ficou complexo sem percebermos. 

Generalizando o ponto levantado: o desenvolvedor, ao invés de partir 
para uma solução mais abstrata, que resolveria o problema de forma genérica, 
prefere ficar postergando a implementação final, com a desculpa de estar prat- 
icando passos de bebê. 

Imagine isso em um problema do mundo real, complexo e cheio de casos 
excepcionais. Na prática, o que acontece é que o programador gasta tanto 
tempo “contornando” a solução que resolveria o problema de uma vez que, 
quando chega a hora de generalizar o problema, ele se perde. Em sessões de 


53 


4.3. Passos de bebé (ou Baby steps) Casa do Código 





Coding Dojo, onde os programadores se juntam para praticar TDD, é comum 
ver sessões que duram muito tempo e, ao final, os desenvolvedores pouco 
avançaram no problema. 

Isso é simplesmente uma má interpretação do que são passos de bebê. O 
desenvolvedor deve buscar pela solução mais simples, e não pela modifi- 
cação mais simples. Veja que a modificação mais simples não é necessaria- 
mente a solução mais simples. 

No começo, modificações mais simples podem ajudar o desenvolvedor 
a pensar melhor no problema que está resolvendo; esse foi o caso quando 
implementamos o return 1350.0. Mas, caso o desenvolvedor continue 
somente implementando as modificações mais simples, isso pode afastá-lo 
da solução mais simples, que é o que o desenvolvedor deveria estar buscando 
ao final. Isso pode ser exemplificado pela sequência de if que fizemos, na 
qual, ao invés de partirmos para a solução correta (igual fizemos no capítulo 
anterior), optamos pela modificação mais simples. 





CoDING Dojo 


Um coding dojo é um encontro de desenvolvedores que estão interes- 
sados em aprender alguma coisa nova, como uma linguagem de progra- 
mação diferente, ou técnicas de desenvolvimento diferentes. O objetivo 
é criar um ambiente tranquilo e favorável a novos aprendizados. 

A prática mais comum é juntar alguns desenvolvedores e projetar uma 
máquina na parede. Dois desenvolvedores sentam em frente ao com- 
putador e começam a resolver algum problema predeterminado, usando 
a linguagem e/ou a prática que desejam aprender melhor. 

Geralmente esses dois desenvolvedores têm apenas alguns minutos 
para trabalhar. Enquanto eles trabalham a plateia assiste e eventualmente 
sugere alterações para o “piloto e copiloto” Ao final do tempo (geral- 
mente 7 minutos), o copiloto vira piloto, o piloto volta para a plateia, e 
alguém da plateia se torna “copiloto”. 

Você pode ler mais sobre coding dojos, diferentes estilos, problemas 
sugeridos nas mais diversas referências na internet [7]. 











54 


Casa do Cédigo Capitulo 4. Simplicidade e Baby Steps 





Veja as imagens a seguir. Nelas, temos o código e as possíveis soluções 
para o problema. Dentro desse conjunto, existem as que são resolvidas pelas 
mudanças mais simples, que podem, ou não, ser a solução mais simples tam- 
bém para o problema: 





Se o desenvolvedor continuamente opta pela modificação mais simples 
que não é a solução mais simples, isso só vai afastá-lo da melhor solução: 
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Em nosso exemplo, veja que a solução mais simples acabou sendo a uti- 
lização de ifs. Sabemos que todo condicional faz o código ser mais difícil 
de ser mantido e de ser testado. Sabemos que essa não é a melhor solução 
para o problema; o uso de polimorfismo seria mais adequado. Nesse prob- 
lema específico, discutiremos como resolvê-lo da melhor forma nos capítulos 
posteriores. 

Novamente, resumindo a discussão: a mudança mais simples para re- 
solver um problema não é necessariamente a solução mais simples para 
resolvê-lo. 

Os passos de bebê servem para ajudar o desenvolvedor a entender melhor 
o problema e diminuir o passo caso ele não se sinta confortável com o prob- 
lema que está resolvendo. Se o desenvolvedor está implementando um trecho 
de código complexo e tem dúvidas sobre como fazê-lo, ele pode desacelerar e 
fazer implementações mais simples; mas caso esteja seguro sobre o problema, 
ele pode tomar passos maiores e ir direto para uma implementação mais ab- 
strata. 

O próprio Kent Beck comenta sobre isso em seu livro. Em seu exem- 
plo, ele implementa uma classe Dinheiro, responsável por representar uma 
unidade monetária e realizar operações sobre ela. No começo, ele toma passos 
simplórios, como os feitos aqui, mas finaliza o capítulo dizendo que ele não 
toma passos pequenos o tempo todo; mas que fica feliz por poder tomá-los 
quando necessário. 
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CÓDIGO DUPLICADO ENTRE O CÓDIGO DE TESTE E O CÓDIGO 
DE PRODUÇÃO 


Todo desenvolvedor sabe que deve refatorar qualquer duplicidade de 
código no momento que a encontrar. No próprio problema da soma, a 
duplicidade já aparece logo no primeiro teste: repare que o “1”, “2” exis- 
tentes no código de testes está duplicado com o “I” e “II” no código de 
produção. É fácil ver que cada “T”, adiciona 1 no número final. Sim, você 
deve ficar atento com duplicidade de código entre a classe de teste e a 
classe de produção. Nesse caso, após o teste ficar verde, o desenvolve- 
dor poderia já refatorar o código de produção para algo mais genérico, e 
resolver a duplicidade. 

O mesmo acontece em nosso código. No momento em que colocamos 
o valor “1350.0” fixo em nosso código de produção, geramos uma dupli- 
cação. O mesmo valor estava no código de teste: “1500.0 * 0.9”. Nesse mo- 
mento, o desenvolvedor já poderia ter refatorado e generalizado a solução 
para algo como funcionario.getSalario() + 0.9. 











4.4 USANDO BABY STEPS DE MANEIRA CONSCIENTE 


De volta ao problema da calculadora de salário, vamos repetir a implemen- 
tação, mas dessa vez usando passos de bebê de forma consciente e produtiva. 


Novamente, o primeiro teste: 


public function 
testCalculoSalarioDesenvolvedoresComSalarioAbaixoDoLimite() 


{ 
$calculadora = new CalculadoraDeSalario(); 
$desenvolvedor = new Funcionario( 

"Andre", 1500.0, TabelaCargos: : DESENVOLVEDOR) ; 
$salario = $calculadora->calculaSalario($desenvolvedor) ; 
$this->assertEquals(1500.0 * 0.9, $salario, null, 0.00001); 

} 
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Vamos fazê-lo passar da maneira mais simples possível: 


public function calculaSalario(Funcionario $funcionario) 


{ 
return 1500 * 0.9; 


Mas, dessa vez, ao contrário de partir para o próximo teste, vamos re- 
mover a duplicação de dado que existe entre o código de teste e o código de 
produção: 


public function calculaSalario(Funcionario $funcionario) 
{ 


return $funcionario->getSalario() * 0.9; 


Já está melhor. O código já está genérico e mais perto da solução final. O 
próximo teste garante o desconto correto para desenvolvedores que ganham 


acima do limite: 


public function 
testCalculoSalarioDesenvolvedoresComSalarioAcimaDoLimite() 


{ 
$calculadora = new CalculadoraDeSalario(); 
$desenvolvedor = new Funcionario( 

"Andre", 4000.0, TabelaCargos: :DESENVOLVEDOR) ; 
$salario = $calculadora->calculaSalario($desenvolvedor) ; 
$this->assertEquals(4000.0 * 0.8, $salario, null, 0.00001); 

} 


Nesse momento, não há dúvidas de como será a implementação. Pre- 
cisamos verificar o salário do desenvolvedor. Se ele for maior que R$3000,00, 
devemos descontar 20%. Caso contrário, descontamos os mesmos 10%. 
Como a implementação está bem clara em nossa cabeça, podemos ir direto 
para a solução final: 


public function calculaSalario(Funcionario $funcionario) 


{ 
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if ( $funcionario->getSalario() > 3000 ) 1 
return $funcionario->getSalario() * 0.8; 


} 


return $funcionario->getSalario() * 0.9; 


Veja a diferença dos passos de bebê nos dois testes que escrevemos. No 
primeiro, tomamos a decisão mais simples possível na hora de fazer o teste 
passar. Mas, logo em seguida, seguimos o ciclo de TDD à risca: removemos a 
duplicação de código que já existia. No segundo teste, estávamos seguros de 
como fazer a implementação, e a buscamos diretamente. 

Será que praticamos TDD errado? Lembre-se que o objetivo do desen- 
volvedor não é praticar TDD, mas sim entregar código de qualidade. TDD 
e passos de bebê estão lá para ajudar, mas não são regra de ouro. Um bom 
programador sabe a hora de ir mais devagar (geralmente quando está pas- 
sando por um problema complicado do ponto de vista lógico ou do ponto de 
vista de design de classes) e realmente usar passos de bebê, e também sabe a 
hora de acelerar um pouco mais (geralmente quando não há muitas dúvidas 
sobre como resolver o problema ou sobre como projetar a classe), ganhando 
em produtividade. 

Continuaremos a implementação desta calculadora nos próximos capítu- 
los. Vamos agora finalizar nossa discussão sobre passos de bebê. 
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UNCLE BOB E OS PASSOS DE REFATORAÇÃO DO TDD 


Há alguns anos atrás, Robert Martin fez um post em seu blog sobre 
uma suposta sequência de passos de refatoração que levariam o desen- 
volvedor ao melhor código [28]. Seguindo a ideia dos baby steps, ele co- 
menta que um código de produção começa bem específico e caminha até 
em direção a generalização, para que atenda o problema por completo. 

Segundo ele, na hora de generalizar o código, se você usasse baby steps 
e seguisse as refatorações na sequência que ele descreveu, você sempre 
chegaria ao melhor algoritmo possível para aquele código. Era como se 
ele tivesse uma maneira mecânica para se produzir código de qualidade. 

Alguns dias depois, eu (Maurício Aniche) e o Guilherme Silveira 
respondemos ao post, mostrando nosso ponto contrário. Em nossa 
opinião, não é possível criar uma simples sequência de passos para se 
chegar ao melhor algoritmo possível. Novamente, a experiência e con- 
hecimento do desenvolvedor são necessários. 

Por fim, o ponto é que é realmente difícil saber o tamanho do passo a 
ser dado, e como refatorar o código para que ele fique cada vez melhor. 
Sua experiência deve ser levada em conta nessa hora. 








VANTAGEM DE FAZER O TESTE PASSAR RÁPIDO 


Uma das vantagens de fazer o teste passar de maneira simples e rápida 
é “testar o teste”. Seu teste é código; e ele pode ter bugs também. 

Como não faz sentido escrever um teste para o teste, uma maneira 
de testá-lo é garantir que ele falhe quando precisa falhar, e passe quando 
precisa passar. Ou seja, antes de começar a implementação, veja o teste 
falhar. Com ele falhando, tente fazê-lo passar da maneira mais simples 
possível, com o objetivo apenas de vê-lo ficando verde. Dessa forma, você 
cc, » 

testou o teste. 
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4.5 CONCLUSÃO 


Neste capítulo, discutimos sobre os famosos baby steps. A ideia é possibili- 
tar ao desenvolvedor andar na velocidade que achar necessário. Se o código 
que ele está implementando naquele momento é complicado e/ou complexo, 
tomar passos de bebê podem ajudá-lo a entender melhor o problema e a bus- 
car por soluções mais simples. 

Mas, se o código em que ele está trabalhando é algo que já está bem claro 
e não há muitas dúvidas sobre a implementação, o desenvolvedor pode então 
dar um passo um pouco maior, já que passos pequenos farão com que ele 
apenas diminua sua produtividade. 

No fim, a grande vantagem dos passos de bebê é poder aprender algo 
sobre o código para que ele possa ser melhorado. Se o desenvolvedor não 
está aprendendo nada, então talvez não haja razão para dar passos de bebê 
naquele instante. 

Discutimos também que a modificação mais simples não é necessari- 
amente a solução mais simples que resolve o problema. Desenvolvedores 
devem buscar simplicidade não apenas no nível de código, mas também no 
nível de design de classes. Às vezes, um simples if pode ser o código mais 
simples a ser escrito, mas talvez não seja a melhor solução do ponto de vista 
do design. 

Use baby steps com parcimônia. Um bom praticante de TDD sabe a hora 
de aumentar ou diminuir o passo. Use os passos de bebê para o bem do seu 
projeto, e não simplesmente porque é uma regra. Parafraseando Jason Gor- 
man, “se fazer a coisa mais simples significa fazer uso de muitos ifs ou switchs, 
muito provavelmente você não entendeu TDD. 
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CAPITULO 5 


TDD e design de classes 


Como dito anteriormente, TDD é bastante popular pelos seus efeitos posi- 
tivos no design das classes do nosso sistema. Neste capítulo, começaremos a 
discutir como os testes podem efetivamente ajudar desenvolvedores a pensar 
melhor em relação às classes que estão criando. 


5.1 O PROBLEMA DO CARRINHO DE COMPRAS 


Suponha agora que o projeto atual seja uma loja virtual. Essa loja virtual pos- 
sui um carrinho de compras, que guarda uma lista de itens comprados. Um 
item é basicamente um produto e possui a descrição, a quantidade, o valor 
unitário e o valor total. Veja o código que representa esse carrinho: 


namespace CDC\Loja\Carrinho; 
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use Loja\Produto\Produto; 


use Array0Object; 


class CarrinhoDeCompras 


{ 


private $produtos; 


public function __construct() 


{ 
$this->produtos = new ArrayObject(); 
} 
public function adiciona(Produto $produto) 
{ 
$this->produtos->append ($produto) ; 
return $this; 
} 


public function getProdutos() 


{ 
return $this->produtos; 
} 
// ... restante da classe, apresentado no capítulo 2 


Um produto também é uma simples classe com a diferença de que agora 


evoluiremos a mesma adicionando um novo atributo, a quantidade, alterando 


oatributo valor para valorUnitario e criando um método para retornar 


o valor total: 


namespace CDC\Loja\Produto; 


class Produto 


{ 
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private $valorUnitario; 
private $quantidade 
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public function __construct($nome, $valorUnitario, 


$quantidade = 1) 


{ 
$this->nome = $nome; 
$this->valorUnitario = $valorUnitario; 
$this->quantidade = $quantidade; 

} 


function getNome() 
{ 


return $this->nome; 


function getValorUnitario() 
{ 


return $this->valorUnitario; 


function getQuantidade() 


{ 
return $this->quantidade; 
} 
public function getValorTotal() 
{ 
return $this->valorUnitario * $this->quantidade; 
} 


Agora imagine que o programador deva implementar uma funcionali- 
dade que devolva o valor do item de maior valor dentro desse carrinho de 
compras. Pensando já nos testes, temos os seguintes cenários: 


e Seo carrinho só tiver um item, ele mesmo será o item de maior valor. 


e Seo carrinho tiver muitos itens, o item de maior valor é o que deve ser 
retornado. 
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e Um carrinho sem nenhum item deve retornar zero. 


Seguindo TDD à risca, vamos começar pelo cenário mais simples, 
que nesse caso é o carrinho vazio. Vamos criar um teste para a classe 
MaiorPreco, responsável por essa tarefa: 


namespace CDC\Loja\Carrinho; 

use CDC\Loja\Test\TestCase, 
CDC\Loja\Carrinho\CarrinhoDeCompras, 
CDC\Loja\Carrinho\MaiorPreco; 


class MaiorPrecoTest extends TestCase 


{ 
public function testDeveRetornarZeroSeCarrinhoVazio() 
{ 
$carrinho = new CarrinhoDeCompras() ; 
$algoritmo = new MaiorPreco(); 
$valor = $algoritmo->encontra($carrinho) ; 
$this->assertEquals(0, $valor, null, 0.0001); 
} 
} 


Fazer esse teste passar é fácil; basta retornar zero. 


namespace CDC\Loja\Produto; 


use CDC\Loja\Carrinho\CarrinhoDeCompras; 


class MaiorPreco 


{ 
public function encontra(CarrinhoDeCompras $carrinho) 
{ 
return 0; 
} 
} 
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No entanto, este teste não passa ainda. Isso porque mudamos um pouco 
a forma de estender nossa classe de teste do PHPUnit, agora fazemos isso a 
partir de uma classe chamada TestCase, a qual será descrita a seguir. 
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CRIANDO UM TEST CASE 


No código do teste anterior é possível perceber que não é mais real- 
izado o require do autoload.php como nos testes dos capítulos an- 
teriores. Isso se dá ao fato de que criamos uma nova classe respon- 
sável por montar o ambiente inicial de todo e qualquer teste que exe- 
cutarmos. Essa classe chama-se TestCase e está situada no names- 
pace CDC\Loja\Test. Como trata-se de uma classe que nos auxiliará a 
preparar o ambiente de testes, precisamos incluir o autoload. php ger- 
ado pelo Composer. A seguir está a estrutura de nossa classe Test Case 
que deverá ser criada em src/CDC/Loja/Test/TestCase.php. 


namespace CDC\Loja\Test; 
require "./vendor/autoload.php"; 
use PHPUnit Framework TestCase as PHPUnit; 


class TestCase extends PHPUnit 


{ 
protected function setUp() 
{ 
parent: : setUp(); 
} 
protected function tearDown() 
{ 
parent: :tearDown(); 
} 
+ 


Agora para a utilização do ambiente de testes previamente config- 
urado (podendo ser adicionadas diversas funcionalidades nos méto- 
dos setUp e tearDown) basta definir em toda nova classe de testes 
o seguinte: use CDC\Loja\Test\TestCase, fazendo-a estender de 


TestCase. 
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Ainda não há uma repetição de código grande a ser eliminada, então 
podemos ir para o próximo teste, que é o caso de o carrinho conter apenas 
um produto. O teste: 


// 


use CDC\Loja\Produto\Produto; 
// 


public function 
testDeveRetornarValorDoItemSeCarrinhoComiElemento() 


{ 
$carrinho = new CarrinhoDeCompras () ; 
$carrinho->adiciona(new Produto("Geladeira", 1, 900.00)); 
$algoritmo = new MaiorPreco() ; 
$valor = $algoritmo->encontra($carrinho) ; 
$this->assertEquals (900.00, $valor, null, 0.0001); 

} 


Para fazer esse teste passar, precisaremos escrever um pouco mais de 
código. Mas não há muitas dúvidas sobre o algoritmo nesse momento: se o 
carrinho estiver vazio, retorna o. Caso contrário, retorna o valor do primeiro 
elemento desse carrinho: 


public function encontra(CarrinhoDeCompras $carrinho) 


{ 
if ( count($carrinho->getProdutos()) === 0 ) { 
return 0; 


} 
return $carrinho->getProdutos() [0] ->getValorTotal (); 


Por fim, o cenário que resta: é necessário encontrar o item de maior valor 
caso o carrinho contenha muitos itens: 


public function 
testDeveRetornarMaiorValorSeCarrinhoComMuitosElementos () 
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{ 
$carrinho = new CarrinhoDeCompras () ; 
$carrinho->adiciona(new Item("Geladeira", 1, 900.00)); 
$carrinho->adiciona(new Item("Fogão", 1, 1500.00)); 
$carrinho->adiciona(new Item("Máquina de lavar", 1, 750.00)); 
$algoritmo = new MaiorPreco(); 
$valor = $algoritmo->encontra($carrinho) ; 
$this->assertEquals(1500.00, $valor, null, 0.0001); 

} 


Vamos à implementação. E necessário navegar pelos itens da coleção, 
procurando pelo item de maior valor total. Para armazenar esse maior valor, 


precisamos de uma variável, batizada de maiorValor: 


public function encontra(CarrinhoDeCompras $carrinho) 


{ 
if ( count ($carrinho->getProdutos()) === 0 ) { 
return 0; 


$maiorValor = $carrinho->getProdutos() [0] ->getValorTotal (O); 
foreach($carrinho->getProdutos() as $produto) { 
if ( $maiorValor < $produto->getValorTotal (O) ) 1 
$maiorValor = $produto->getValorTotal() ; 


return $maiorValor; 


Com todos os testes passando, é hora de avaliá-los. Observe, por 
exemplo, o último teste que escrevemos. Veja que o teste instancia a 
classe MaiorPreco, passa para ela um “carrinho” e verifica o retorno 
desse método. Repare que todo o cenário montado foi em cima da classe 
CarrinhoDeCompras; não fizemos nada na classe MaiorPreco 
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Isso pode ser um mau sinal. Sabemos que uma das vantagens da ori- 
entação a objetos em relação a códigos mais procedurais é justamente a ca- 
pacidade de unir dados e comportamentos. A classe MaiorPreco parece 
“estranha”, já que não houve necessidade de setar atributos ou qualquer outro 
dado nela. 

Sabendo desse possível problema na classe, vamos ver seu código. Repare 
que o método encontra () faz uso do carrinho praticamente o tempo 
todo, e não faz uso de nada específico da sua própria classe. 

A pergunta é: por que criamos essa classe? Por que o método 
encontra () não está dentro da própria classe CarrinhoDeCompras? 

Vamos fazer essa mudança. Se levarmos toda a lógica do método 
encontra () para um método chamado, por exemplo, maiorValor () den- 
tro do CarrinhoDeCompras, a classe ficará assim: 


public function maiorValor() 


{ 
if (count ($this->getProdutos()) === 0) É 
return 0; 


$maiorValor = $this->getProdutos() [0] ->getValorUnitario() ; 
foreach ($this->getProdutos() as $produto) { 
if ($maiorValor < $produto->getValorUnitario()) { 
$maiorValor = $produto->getValorUnitario(); 


return $maiorValor; 


Já os testes ficarão assim: 


namespace CDC\Loja\Carrinho; 
use CDC\Loja\Test\TestCase, 


CDC\Loja\Carrinho\CarrinhoDeCompras, 
CDC\Loja\Produto\Produto; 
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class CarrinhoDeComprasTest extends TestCase 


{ 
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public function testDeveRetornarZeroSeCarrinhoVazio() 
{ 
$carrinho = new CarrinhoDeCompras() ; 
$valor = $carrinho->maiorValor () ; 
$this->assertEquals(0, $valor, null, 0.0001); 


public function 
testDeveRetornarValorDoItemSeCarrinhoComiElemento () 


{ 
$carrinho = new CarrinhoDeCompras() ; 
$carrinho->adiciona(new Produto("Geladeira", 900.00, 1)); 
$valor = $carrinho->maiorValor () ; 
$this->assertEquals (900.00, $valor, null, 0.0001); 

} 


public function 
testDeveRetornarMaiorValorSeCarrinhoComMuitosElementos () 


{ 
$carrinho = new CarrinhoDeCompras() ; 
$carrinho->adiciona(new Produto("Geladeira", 900.00, 1)); 
$carrinho->adiciona(new Produto("Fog&o", 1500.00, 1)); 
$carrinho->adiciona( 

new Produto ("Máquina de lavar", 750.00, 1)); 

$valor = $carrinho->maiorValor (); 
$this->assertEquals(1500.00, $valor, null, 0.0001); 

} 
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Veja agora que nosso teste está muito mais claro e elegante. Os testes do 
CarrinhoDeCompras instanciam um carrinho, montam o cenário desejado 
e invocam um método do próprio carrinho. O código dentro do teste parece 
melhor e mais orientado a objetos. O comportamento está no lugar esperado. 
É justamente isso que se espera de um código de qualidade. 

Antes de continuarmos, vamos refletir um pouco sobre como descarta- 
mos a primeira solução e chegamos à solução que melhor resolveu o prob- 
lema. 


5.2 TESTES QUE INFLUENCIAM NO DESIGN DE CLASSES 


O que nos fez optar pelo segundo caminho ao invés do primeiro? Em que mo- 
mento mudamos o rumo da implementação? Releia o texto anterior. Repare 
que o que nos fez mudar de ideia foi justamente o fato de termos encontrado 
um teste com uma característica estranha (a não necessidade de um cenário 
para a classe sob teste). 

Esse é o principal ponto deste capítulo. Muitos praticantes de TDD afir- 
mam que a prática lhes guia no projeto de classes. A grande pergunta é: como 
isso acontece? Isso é outro ponto bastante curioso e mal entendido sobre 
TDD. Apesar de muitos praticantes de TDD acreditarem que a prática guia a 
criação do design, poucos sabem explicar como isso realmente acontece. Este 
é, aliás, o grande ponto que este livro tenta atacar. 

A prática de TDD pode influenciar no processo de criação do projeto de 
classes. No entanto, ao contrário do que afirmações mais superficiais fazem 
parecer, a prática de TDD não guia o desenvolvedor para um bom projeto 
de classes de forma automática; a experiência e conhecimento do desen- 
volvedor são fundamentais ao criar software orientado a objetos. 

A prática, por meio dos seus possíveis feedbacks em relação ao projeto de 
classes, que serão discutidos em detalhes nos capítulos a seguir, pode servir de 
guia para o desenvolvedor. Esses feedbacks, quando observados, fazem com 
que o desenvolvedor perceba problemas de projeto de classes de forma ante- 
cipada, facilitando a refatoração do código. Um exemplo desses feedbacks foi 
justamente o que observamos no primeiro teste que escrevemos. O teste não 
montava qualquer cenário na classe que estava sob teste. Isso simplesmente 
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não parecia correto. São pequenas dicas como essas que ajudam o desenvolve- 
dor a optar por um melhor projeto de classes. 

Portanto, esta é a forma na qual a prática guia o desenvolvedor para um 
melhor projeto de classes: dando retorno constante sobre os possíveis proble- 
mas existentes no atual projeto de classes. É tarefa do desenvolvedor perceber 
esses problemas e melhorar o projeto de acordo. 


5.3 DIFERENÇAS ENTRE TDD E TESTES DA MANEIRA 
TRADICIONAL 


O desenvolvedor que pratica TDD escreve os testes antes do código. Isso faz 
com que o teste de unidade que está sendo escrito sirva de rascunho para o 
desenvolvedor. Foi novamente o que fizemos. Começamos pelo teste e, ao 
perceber que o teste “estava estranho”, o jogamos fora e começamos outro. O 
custo de jogá-lo fora naquele momento era quase zero. Não havíamos escrito 
uma linha na classe de produção. Tínhamos a chance de começar de novo, 
sem qualquer perda. 

Mas o mesmo feedback poderia ser obtido caso o desenvolvedor deixasse 
para escrever o teste ao final da implementação. Mas então qual seria a van- 
tagem da prática de TDD? 

Ao deixar a escrita do teste somente para o final, no momento em que o 
desenvolvedor percebesse um problema de design graças ao teste, o custo de 
mudança seria alto. Leve isso para o mundo real, onde o programador escreve 
dezenas de classes que interagem entre si e só depois ele escreve o teste. 

Todas as decisões de design (boas ou ruins) já foram tomadas. Mudar 
algo nesse momento pode ser caro, afinal uma mudança em uma classe pode 
impactar em muitas mudanças nas outras classes que dependem da que foi 
alterada. 

O praticante de TDD não tem esse problema. Afinal, graças à escrita 
do teste antes e à simplicidade inerente do processo, ele escreve um teste 
para uma pequena funcionalidade, recebe feedback dela, faz as mudanças que 
achar necessário e implementa. Depois, ele repete o ciclo. Ou seja, o prati- 
cante de TDD recebe feedback constante ao longo do seu dia a dia de trabalho, 
fazendo-o encontrar possíveis problemas de design mais cedo e, por conse- 
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quência, diminuindo o custo de mudança. 





FISHBOWLING NO ENCONTRO ÁGIL 


Ao longo do meu mestrado, participei e conversei com diversas pes- 
soas praticantes ou interessadas em TDD. Em um desses eventos, o En- 
contro Ágil de 2010, organizei um pequeno debate sobre o assunto [30]. 
Éramos em torno de 12 pessoas discutindo sobre TDD (eu não participei 
da discussão, apenas a moderei), e ficamos lá por 1h30. 

Durante toda a conversa, praticamente todos os participantes afir- 
mavam firmemente que TDD os ajudava a produzir classes melhores. 
Mas, quando perguntei “como isso acontece exatamente”, todos eles pas- 
saram a falar menos. Eles não sabiam dizer como a prática os guiava, 
apenas “sentiam” que isso acontecia. 

Essa foi uma das grandes motivações da minha pesquisa de mestrado 
e deste livro sobre o assunto. Realmente não é claro para todos como 
TDD guia o desenvolvedor. Espero com este livro mostrar, de maneira 
explícita, como isso acontece. 











5.4 TESTES COMO RASCUNHO 
Observe o teste a seguir: 


public function 
testDeveRetornarValorDoItemSeCarrinhoComiElemento() 


{ 
$carrinho = new CarrinhoDeCompras () ; 
$carrinho->adiciona(new Produto("Geladeira", 900.00, 1)); 
$valor = $carrinho->maiorValor() ; 
$this->assertEquals (900.00, $valor, null, 0.0001); 

} 


Repare que, apesar de simples, ele deixa bem clara uma grande quanti- 
dade de decisões tomadas na classe CarrinhoDeCompras: 


75 


5.4. Testes como rascunho Casa do Código 





e O nome do método que calculará o maior valor (maiorValor ()); 
e O nome do método que recebe um novo item (adiciona ()); 
e Os parâmetros que esses métodos recebem (um Item); 


e O retorno do método (um float). 


Todas elas são decisões de design! Se alguma dessas decisões não agradar 
ao programador, ele pode simplesmente mudar de ideia. O teste serve como 
um rascunho para o desenvolvedor, no qual ele pode experimentar as difer- 
entes maneiras de se projetar a classe. 

E o teste, na verdade, é um excelente rascunho. O teste é o primeiro 
“cliente” da classe que está sendo criada. Ele é a primeira classe que está inter- 
agindo com ela. E olhar para ele com esse ponto de vista pode fazer sentido. 
Se está difícil testar um comportamento, é porque, muito provavelmente, sua 
classe está mal projetada. 

Um teste no fim das contas é apenas uma classe que instancia a classe sob 
teste e invoca um comportamento (método), passando um cenário determi- 
nado. Como isso poderia ser difícil? Se está, novamente, talvez sua classe es- 
teja muito acoplada ou seja pouco coesa (possua responsabilidades demais). 
Um programador atento percebe que está difícil escrever o teste e muda de 
ideia em relação ao design da classe que está criando. Testar deve ser uma 
atividade fácil e prazerosa. 

O próprio Michael Feathers [19] já escreveu um post sobre isso, e ele 
sumariza a discussão dizendo que existe uma relação muito forte entre uma 
classe fácil de testar e uma classe que está bem projetada. 

Dada essa grande relação entre um código fácil de ser testado e um código 
de qualidade, será difícil separar TDD de design de classes daqui para a frente. 
Por esse motivo, ao final do livro, encontra-se um apêndice sobre design de 
classes. Nele, discutimos os princípios SOLID, um conjunto de 5 boas ideias 
de orientação a objetos. Esses princípios discutem basicamente as vantagens 
de se ter classes coesas, pouco acopladas e simples. Caso o leitor não esteja 
familiarizado com estes princípios, é sugerido que ele o leia; conhecer estes 
princípios facilitará a leitura dos próximos capítulos. 


76 


Casa do Código Capítulo 5. TDD e design de classes 





5.5 CONCLUSÃO 


Já vimos que os testes podem influenciar o design das classes que estamos 
desenvolvendo. Ao observar o código do teste de unidade com atenção, o de- 
senvolvedor pode perceber problemas no projeto de classes que está criando. 
Problemas esses como classes que possuem diversas responsabilidades ou que 
possuem muitas dependências. 

Ao escrever um teste de unidade para uma determinada classe, o de- 
senvolvedor é obrigado a passar sempre pelos mesmos passos: a escrita do 
cenário, a execução da ação sob teste e, por fim, a garantia de que o compor- 
tamento foi executado de acordo com o esperado. Uma dificuldade na escrita 
de qualquer uma dessas partes pode implicar em problemas no projeto de 
classes. O desenvolvedor, atento, percebe e melhora seu projeto de classes de 
acordo. 

Ao longo do livro, descreveremos padrões que podem ajudar o praticante 
a perceber problemas de design específicos, como baixa coesão, alto acopla- 
mento e complexidade desnecessária. 
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CAPITULO 6 


Qualidade no código do teste 


No capítulo anterior, discutimos que os testes podem eventualmente indicar 
problemas no código do teste. Com essa informação em mãos, desenvolve- 
dores podem refatorar o código e melhorá-lo. Mas, para que isso aconteça, o 
código do teste deve ser o mais claro e limpo possível. 

Escrever testes deve ser algo fácil e produtivo. Todas as boas práticas que o 
desenvolvedor aplica no código de produção podem ser utilizadas no código 
do teste também, para que ele fique mais claro e mais reutilizável. 

Nas seções a seguir, discutiremos práticas que tornam os testes mais fáceis 
de ler e manter. 


6.1. Repetição de código entre testes Casa do Código 








A EQUIPE QUE ODIAVA OS TESTES 


Uma vez, conversando com um aluno, ele me comentou que a equipe 
escrevia testes e que o projeto em que atuavam possuía uma bateria de 
testes imensa, mas pasmem: eles odiavam os testes! 

Curioso pelo assunto, comecei a fazer perguntas para entender mel- 
hor qual era o real problema deles. Após alguns minutos de conversa, 
descobri que o que os incomodava era o fato de que qualquer alteração 
simples no código de produção impactava em profundas alterações no 
código dos testes. Ou seja, eles gastavam 30 segundos implementando 
uma nova funcionalidade, e 30 minutos alterando testes. 

Por que isso aconteceu? A resposta é simples: falta de cuidado com o 
código dos testes. Agora nossos testes são automatizados, eles são código. 
E código ruim impacta profundamente na produtividade da equipe. 

Todo o carinho que os desenvolvedores têm com seus códigos de pro- 
dução deve acontecer também com o código de testes. Evitar repetição 
de código, isolar responsabilidades em classes específicas etc. são funda- 
mentais para que sua bateria de testes viva para sempre. 











6.1 REPETIÇÃO DE CÓDIGO ENTRE TESTES 


Veja a classe CarrinhoDeComprasTest. Ela contém apenas 3 testes, mas 
repare na quantidade de código repetido que já existe. Veja que todos os testes 
possuem a linha que instancia o carrinho de compras. E, muito provavel- 
mente, os próximos testes para essa classe conterão o mesmo conjunto de 
linhas. 


namespace Loja\Carrinho; 


class CarrinhoDeComprasTest extends TestCase 
{ 
public function testDeveRetornarZeroSeCarrinhoVazio() 
{ 
$carrinho = new CarrinhoDeCompras() ; 
// continuação do teste aqui... 


80 


Casa do Código Capitulo 6. Qualidade no cédigo do teste 





public function 
testDeveRetornarValorDoItemSeCarrinhoComiElemento () 


$carrinho = new CarrinhoDeCompras () ; 


// continuação do teste aqui... 


public function 
testDeveRetornarMaiorValorSeCarrinhoComMuitosElementos () 


$carrinho = new CarrinhoDeCompras () ; 


// continuação do teste aqui... 


Imagine se, por algum motivo, o construtor da classe 
CarrinhoDeCompras mudar. A mudança deverá acontecer em quan- 
tos testes? Imagine se essa classe contivesse 100 testes; seria necessário alterar 
em 100 pontos diferentes. 

É bem claro para todo desenvolvedor que qualquer código repetido é 
problemático. Se surge a necessidade de mudar esse código, ele deve alterar 
em todos os pontos cujo código se repete. Isso torna a manutenção cara. O 
mesmo ponto vale para os testes. 

A solução, portanto, é escrever esse código em apenas um único lugar. 
Algo como um método de inicialização da classe de teste. O PHPUnit possui 
uma alternativa simples e elegante para isso. Basta criar o método setUp () 
e o PHPUnit se encarregará de invocar esse método antes de cada teste. Veja 
como o código fica muito mais claro, com o método setUp centralizando a 
criação do cenário inicial. Cada método de teste agora é muito mais simples 
de ser lido: 


namespace CDC\Loja\Carrinho; 


81 


6.1. Repetição de código entre testes Casa do Código 





use CDC\Loja\Test\TestCase, 


CDC\Loja\Carrinho\CarrinhoDeCompras, 
CDC\Loja\Produto\Produto; 


class CarrinhoDeComprasTest extends TestCase 


{ 
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private $carrinho; 


protected function setUp() 

{ 
$this->carrinho = new CarrinhoDeCompras() ; 
parent :: setUp(); 


public function testDeveRetornarZeroSeCarrinhoVazio() 
4 


$valor = $this->carrinho->maiorValor() ; 
$this->assertEquals(0, $valor, null, 0.0001); 


public function 
testDeveRetornarValorDoItemSeCarrinhoComiElemento () 


{ 
$this->carrinho->adiciona( 
new Produto("Geladeira", 900.00, 1)); 
$valor = $this->carrinho->maiorValor(); 
$this->assertEquals (900.00, $valor, null, 0.0001); 
} 


public function 
testDeveRetornarMaiorValorSeCarrinhoComMuitosElementos () 


$this->carrinho->adiciona( 

new Produto("Geladeira", 900.00, 1)); 
$this->carrinho->adiciona( 

new Produto("Fogão!, 1500.00, 1)); 
$this->carrinho->adiciona( 
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new Produto("Lavadora", 750.00, 1)); 
$valor = $this->carrinho->maiorValor () ; 


$this->assertEquals(1500.00, $valor, null, 0.0001); 


Fazer uso de métodos de inicialização é sempre uma boa ideia. Todo e 
qualquer código repetido nos testes pode ser levado para métodos como esse. 
A vantagem? Novamente, código claro. 





QUANDO USAR TEARDOWN? 


Análoga ao setUp, o método tearDown diz ao PHPUnit para exe- 
cutar esse método logo após a execução do teste. 

Geralmente fazemos uso dele quando queremos “limpar” alguma su- 
jeira que o teste criou. Em testes puramente de unidade, raramente os 
utilizamos. Mas agora imagine um teste que garante que um registro foi 
salvo no banco de dados, ou que um arquivo XML foi escrito no disco. 
Após executarmos o método de teste, precisaremos limpar a tabela ou 
deletar o arquivo gerado. 

Portanto, apesar do setUp não ser útil em testes de unidade, ele é 
extremamente importante em testes de integração. 











6.2 NOMENCLATURA DOS TESTES 


Outro ponto igualmente importante em um teste de unidade é o seu nome. 
Escolher um bom nome pode fazer uma grande diferença na produtividade 
do desenvolvedor. 

Veja, por exemplo, os métodos de teste apresentados na seção anterior. 
Eles validam o funcionamento do método maiorValor (). Imagine que a 


classe de teste fosse parecida com a que segue: 


class CarrinhoDeComprasTest extends TestCase 


{ 
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public function testMaiorValor1() {/* ... */} 
public function testMaiorValor2() {/* ... */} 
public function testMaiorValor3() {/* ... */} 


Se um desses testes falhar, o programador precisará ler o código do teste 
para entender qual o cenário que faz o comportamento quebrar. 

Lembre-se que projetos contêm inúmeros testes de unidade, e se o desen- 
volvedor precisar ler todo o corpo de um método de teste (mais seu método 
de inicialização) para entender o que ele faz perderá muito tempo. É um fato 
que ler código é muito mais difícil do que escrever código [33]. A escolha de 
um bom nome do teste pode ajudar o desenvolvedor a ler menos. 

Uma sugestão é deixar bem claro no nome do teste qual o comportamento 
esperado da classe perante determinado cenário. Por exemplo, veja os nomes 
de testes que demos anteriormente: 


class CarrinhoDeComprasTest extends TestCase 
1 
public function testDeveRetornarZeroSeCarrinhoVazio() 


{ /* ... */ 5 


public function 
testDeveRetornarValorDoItemSeCarrinhoComiElemento () 


{ /* 1... */ 5 


public function 
testDeveRetornarMaiorValorSeCarrinhoComMuitosElementos () 


{ /* 0... */ 5 


Um método cujo nome tenha um tamanho como esse seria considerado 
um pecado em um método de produção. Mas veja que basta o desenvolvedor 
ler o nome do teste para entender quais são os comportamentos esperados 
desta classe. 

Não há uma regra especial para nomear um método de teste (assim como 
não há nenhuma regra clara para nomear classes, métodos e variáveis) e, por- 


tanto, sua equipe pode definir o padrão que achar melhor. A única ressalva, 
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novamente, é que seu nome deixe claro qual o comportamento esperado e 
validado naquele método de teste. 


Underscore no nome do teste 


O PHP utiliza camel case como convenção para nomes de métodos e atrib- 
utos. Ou seja, sempre que desejamos escrever um método com N palavras, 
deixamos a primeira em minúscula, e todas as outras com a sua primeira letra 
em maiúsculo. 


Mas como os nomes dos métodos de teste são extensos ( 





deveRetornarValorDoItemSeCarrinhoComlElemento), muitos 
desenvolvedores optam por usar underscore (_) para separar as palavras e 
facilitar a leitura. Por exemplo, os testes da classe CarrinhoDeCompras 
ficariam assim: 


class CarrinhoDeComprasTest extends TestCase 
{ 


public function test_deve_retornar_zero_se_carrinho_vazio() 


{ /* ... */ 5 


public function 
test deve retornar valor do item se carrinho 1 elemento() 


{ /* ... */ } 


public function 
test retornar maior valor carrinho muitos elementos() 


{ /* ... */ 5 


Se a equipe achar que isso facilitará a leitura e manutenção dos testes, faça. 
Caso contrário, fique na convenção da sua linguagem. 


6.3 POR QUE PREFIXO TEST E SUFIXO TEST? 


Esta é uma característica do framework que estamos utilizando, o PHPUnit. 
Para que uma classe de teste seja reconhecida, ela deve conter o sufixo Test 
em seu nome e estender da classe TestCase do PHPUnit. Para que um 
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método seja reconhecido como um teste unitário, ele deve possuir o prefixo 
test seguido de um nome descritivo do comportamento esperado. 

Em outras linguagens de programação, isso pode ser diferente, como é 
o caso do framework de testes do Java, o JUnit em sua versão 4. Até a ver- 
são 3, a nomenclatura dos testes seguia o padrão que temos atualmente no 
PHP, com o prefixo test nos métodos, sufixo Test no nome da classe e 
a classe estendendo de TestCase. Já em sua versão 4, isso não se faz mais 
necessário; apenas utilizando a anotação @Test já podemos executar nossos 
testes unitários. Outra característica é que com o JUnit 4 não se precisa mais 
estender de TestCase e, desta forma os asserts devem ser importados em 
sua classe de teste. 


6.4 TEST DATA BUILDERS 


Uma outra maneira de reduzir a quantidade de linhas gastas com a criação do 
cenário é criar classes que auxiliam nesse trabalho. Por exemplo, veja a classe 
Carrinho. Para criar um, é necessário passar uma lista de itens. Ou seja, em 
todos os futuros testes que serão escritos, gastaremos ao menos 2 linhas para 
se criar um carrinho. Isso não parece uma boa ideia. 

Veja o pseudocódigo a seguir. Com apenas 1 linha de código, criamos um 
Carrinho com 2 itens no valor de 200,00 e 300,00 reais, respectivamente, 
pronto para ser utilizado pelos testes. 


class CarrinhoDeComprasBuilder () 


{ 
public function comItens() { /* ... */ } 
public function cria() { /* ... */ } 


$carrinho = (new CarrinhoDeComprasBuilder () ) 
->comItens(200.0, 300) 
->cria(); 


Fazendo uso do padrão de projeto Builder [20], podemos facilmente criar 
uma classe como essa. Veja o código a seguir: 
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namespace CDC\Loja\Test\Builder; 


use CDC\Loja\Carrinho\CarrinhoDeCompras, 
CDC\Loja\Produto\Produto; 


class CarrinhoDeComprasBuilder 


{ 
public $carrinho; 
public function __construct() 
{ 
$this->carrinho = new CarrinhoDeCompras () ; 
} 
public function comItens() 
{ 
$valores = func get args(); 
foreach($valores as $valor) { 
$this->carrinho->adiciona( 
new Produto("Item", $valor, 1)); 
} 
return $this; 
} 
public function cria() 
{ 
return $this->carrinho; 
} 
} 


A classe CarrinhoDeComprasBuilder possibilita a criação de um 
carrinho com itens de maneira fácil e rápida. Esse builder pode ainda ser 
melhorado, dando opções para se criar itens com diferentes quantidades etc. 
Lembre-se que você tem todo o poder da orientação a objetos aqui para criar 
classes que facilitem sua vida. 


No fim, você pode implementar Builders da maneira que achar mais con- 
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veniente. Assim como em todo padrão de projeto, os detalhes de implemen- 
tação não são a parte mais importante. Lembre-se que a ideia é facilitar o pro- 
cesso de criação de objetos que serão utilizados em cenários de teste. Classes 
como essas recebem o nome de Test Data Builders [4]. 

Test Data Builders são especialmente úteis quando o teste envolve um 
cenário complexo, cheio de entidades com os mais diferentes valores. Imag- 
ine no mundo real, onde cenários são grandes e complicados. Não fazer uso 
de Builders implica em repetição de muitas linhas de código para se criar 
cenários semelhantes. 

Uma outra vantagem da utilização de Test Data Builders ao longo do 
código de teste é a facilidade na evolução desse mesmo código. Se a classe 
CarrinhoDeCompras mudar, todas as classes de teste que fazem uso dela 
precisarão mudar também. Isso pode ser caro. Ao contrário, se o desen- 
volvedor sempre cria seus cenários a partir de Test Data Builders, qualquer 
mudança na classe será refletida apenas no Builder; bastará ao desenvolvedor 
mexer nele e todos os testes voltarão a funcionar. 


6.5 TESTES REPETIDOS 


Uma frase comum entre desenvolvedores de software é que “melhor do que 
escrever código, é apagar código! 

. A pergunta é: faz sentido apagar um teste? 

A primeira e mais óbvia resposta é: apague o teste quando ele deixar de 
fazer sentido. Se a funcionalidade foi removida, o desenvolvedor deve atu- 
alizar a bateria de testes e apagar todos os testes relacionados a ela. Se a fun- 
cionalidade evoluir, você deve evoluir seus testes juntos. Uma bateria de testes 
desatualizada não serve de nada; só atrapalha o andamento da equipe. 

A segunda resposta é: quando a bateria de testes contiver testes repeti- 
dos. Em algumas situações, desenvolvedores ficam em dúvida sobre como 
implementar determinada funcionalidade, e optam por escrever testes que 
recebem entradas semelhantes. Isso serve para que consigam tomar passos 
menores (baby steps) e cheguem à solução mais simples para o problema. 

No exemplo da Calculadora, o desenvolvedor criaria testes para a soma 
de 1+1, 1+2 € 2+2, por exemplo: 
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namespace CDC\Exemplos; 


use CDC\Loja\Test\TestCase, 
CDC\Exemplos\Calculadora; 


class CalculadoraTest extends TestCase 


{ 
public function testDeveSomarUmMaisUm() 
{ 
$this->assertEquals(2, (new Calculadora())->soma(1,1)); 
} 
public function testDeveSomarUmMaisDois() 
{ 
$this->assertEquals(3, (new Calculadora())->soma(1,2)); 
} 
public function testDeveSomarUmMaisTres() 
{ 
$this->assertEquals(4, (new Calculadora())->soma(1,3)); 
} 
} 


Esses testes, muito úteis durante o tempo de desenvolvimento do algo- 
ritmo, agora se tornaram repetidos. O desenvolvedor deve, portanto, apagá- 
los. Eles, além de serem inúteis, ainda dificultam o trabalho do desenvolve- 
dor. Se um dia o método testado mudar seu comportamento ou sua interface 
pública, o desenvolvedor terá que mudar em 10, 20 testes diferentes (mas que 
no fim testam a mesma coisa). Lembre-se do acoplamento entre seu código 
de teste e seu código de produção. 

Mas será que apenas um teste por funcionalidade é suficiente? Sim. Uma 
bateria de testes deve ter apenas um teste de unidade para cada conjunto de 
estados válidos e inválidos para uma condição de entrada. Espera-se que to- 
dos os elementos de uma classe se comportem de maneira similar dadas duas 
entradas semelhantes. 

Esses conjuntos são conhecidos por classes de equivalência [26]. Es- 
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crever apenas um teste por classe de equivalência é uma prática muito co- 
mum em testes de caixa preta e é conhecida como particionamento em classes 
de equivalência. Essa prática também faz muito sentido em testes de caixa 
branca, como os testes de unidade. 

No exemplo da calculadora, poderíamos ter testes para as seguintes 
classes de equivalência: 


e soma de dois números positivos; 
* soma de um número positivo com outro negativo; 
* soma de um número negativo com outro positivo; 
e soma de dois números negativos; 


e soma com um dos elementos sendo zero. 


Por exemplo, repare que os cenários que somam os valores 1+1 e 5+7, por 
exemplo, pertencem à mesma classe e portanto não precisam de testes para 
cada um destes cenários. Basta o desenvolvedor escolher um deles e escrever 
o teste. 

Uma ótima maneira para garantir que não há testes repetidos é 
de novo apelar para um bom nome de teste. Por exemplo, se o 
nome do teste refere-se diretamente aos valores concretos do cenário, 
como deveSomarUmMaisUm(), sendo que o cenário é claramente a 
soma de (1 + 1), isso sugere ao desenvolvedor que crie um novo teste 
para a mesma classe de equivalência (a existência do método de teste 
deveSomarDoisMaisDois () não “fica estranho”). 

Ao contrário, caso o desenvolvedor opte por dar nomes 
que representam a classe de equivalência como, por exemplo, 
deveSomarDoisNumerosPositivos(), dificilmente o desenvolve- 


dor criará o teste deveSomarDoisNumerosPositivos 2(). 


namespace CDC\Exemplos; 


use CDC\Loja\Test\TestCase, 
CDC\Exemplos\Calculadora; 
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class CalculadoraTest extends TestCase 


{ 


public function testDeveSomarDoisNumerosPositivos() 


{ 
$this->assertEquals(4, (new Calculadora())->soma(2,2)); 


public function testDeveSomarPositivoComNegativo() 


{ 
$this->assertEquals(4, (new Calculadora())->soma(6,-2)); 


public function testDeveSomarNegativoComPositivo() 


{ 
$this->assertEquals(-4, (new Calculadora() )->soma(-6,2)); 


public function testDeveSomarDoisNumerosNegativos() 
{ 
$this->assertEquals(-4, 
(new Calculadora())->soma(-2,-2)); 


} 
public function testDeveSomarComZero () 
{ 
$this->assertEquals(4, (new Calculadora())->soma(4,0)); 
$this->assertEquals(4, (new Calculadora())->soma(0,4)); 
} 


Obviamente, encontrar todas as classes de equivalência não é um trabalho 
fácil, e por isso existe a gigante área de testes de software. Mas fato é que 
não é repetindo teste que o desenvolvedor garante a qualidade do software 
produzido. 
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6.6 ESCREVENDO BOAS ASSERÇÕES 


Boas asserções garantirão que seus testes realmente falharão na hora certa. 
Mas, escrevê-los com qualidade envolve uma série de pequenos detalhes e o 
programador deve estar atento para eles. 

Lembre-se que um bom teste é aquele que falhará quando preciso. E mais, 
ele mostrará o erro da forma mais clara possível. Um primeiro detalhe sim- 





ples, mas importante, é a utilização do método assertEquals (), ou qual- 
quer outro da família. Eles usualmente recebem 2 parâmetros. Como ele com- 
parará se os dois objetos são iguais, então aparentemente a ordem em que os 
passamos não faz diferença. 


$this->assertEquals(a,b); 
$this->assertEquals(b,a); 


No entanto, a ordem é importante para que o PHPUnit apresente a men- 
sagem de erro corretamente. No momento em que um teste falha, o PHPUnit 
mostra uma mensagem parecida com essa: Failed asserting that 4 matches 
expected 3., ou seja, esperava X, mas o valor calculado foi Y. Imagine se essa 
mensagem viesse ao contrário: Failed asserting that 3 matches expected 4.. Isso 
só dificultaria a vida do programador na hora de entender a causa do prob- 
lema. 

Para que ele exiba a mensagem de erro correta, o desenvolvedor deve pas- 
sar os parâmetros na ordem: o primeiro parâmetro é o valor esperado, o se- 
gundo é o valor calculado. Geralmente, o primeiro valor é “fixo” ou vem de 
uma variável declarada dentro do próprio método do teste; já o segundo vem 
geralmente de um objeto que foi retornado pelo método sob teste. 

Ao verificar que o objeto retornado pelo método de teste está correto, o 
desenvolvedor pode fazer uso de mais de um assert no mesmo método. Em 
muitos casos, isso é obrigatório, aliás: seo método sob teste retornou um novo 
objeto, é obrigação do teste garantir que todo seu conteúdo está correto. 

Para isso, o desenvolvedor pode fazer uso de diversos asserts no mesmo 
objeto, um para cada atributo modificado, ou mesmo escrever apenas um, 





mas verificando o objeto inteiro através do método assertEquals (), que 
é invocado pelo PHPUnit. O desenvolvedor deve escolher a alternativa que 
mais lhe agrada. 
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// alternativa 1 
$item = itemQueVeioDoMetodoSobTeste() ; 


$this->assertEquals("Geladeira", $item->getDescricao()) ; 
$this->assertEquals(900.0, $item->getValorUnitario()); 
$this->assertEquals(1, $item->getQuantidade()) ; 
$this->assertEquals(900.0, $item->getValorTotal()); 


// alternativa 2 
$itemQueVeioDoMetodoSobTeste = itemQueVeioDoMetodoSobTeste() ; 
$itemEsperado = new Item("Geladeira", 1, 900.0); 


$this->assertEquals($itemEsperado, $itemQueVeioDoMetodoSobTeste) ; 


Alguns desenvolvedores também gostam de deixar claras as precondições 
do cenário, e o fazem por meio de asserts. Por exemplo, se fôssemos testar o 
método adiciona () do carrinho de compras, garantiriamos que, após a 
invocação do comportamento, o item foi guardado na lista. 

Para isso, verificaríamos o tamanho da lista, que seria 1, por exemplo. 
Mas, para que isso seja verdade, precisamos garantir que o carrinho esteja 
vazio nesse momento. Para tanto, uma asserção pode ser escrita antes de o 
comportamento ser invocado. 


// tests/CDC/Loja/Carrinho/CarrinhoDeComprasTest . php 


public function testDeveAdicionarItens() 

{ 
//garante que o carrinho esta vazio 
$this->assertEmpty ($this->carrinho->getProdutos ()); 


$produto = new Produto("Geladeira", 900.0, 1); 
$this->carrinho->adiciona($produto) ; 


$esperado = count ($this->carrinho->getProdutos()) ; 

$this->assertEquals(1, $esperado) ; 

$this->assertEquals($produto, 
$this->carrinho->getProdutos () [0]); 


93 


6.7. Testando listas Casa do Código 





Essa estratégia deve ser usada com parcimônia. O teste que contém asserts 
como esses pode ser mais difícil de ser lido. 

Com exceção da necessidade de se escrever mais de 1 assert para garan- 
tir o conteúdo de objetos retornados pelo método sob teste, desenvolvedores 
devem evitar ao máximo fazer asserções em mais atributos do que deveria. 

Fuja ao máximo de testes que validam mais de um comportamento. Testes 
devem ser curtos e testar apenas uma única responsabilidade da classe. Por 
exemplo, nos testes da classe CarrinhoDeCompras, o teste que valida o 
método maiorValor() não deve validar o comportamento do método 
adiciona () e vice-versa. 

Testes com duas responsabilidades tendem a ser mais complexos (afinal, 
precisam de mais linhas para montar um cenário que atenda aos dois compor- 
tamentos) e dão menos feedback para o desenvolvedor; se o teste falhar, qual 
das duas responsabilidades não está funcionando de acordo? O desenvolve- 
dor precisará ler o código para entender. Além disso, o nome do método de 
teste pode ficar confuso, já que o desenvolvedor explicará o comportamento 
de duas funcionalidades em uma única frase. 


6.7 TESTANDO LISTAS 


Métodos que retornam listas também merecem atenção especial. Garantir só 
a quantidade de elementos da lista não é suficiente. Isso não garantirá que os 
objetos lá dentro estão como esperado. Portanto, o teste deve também validar 
o conteúdo de cada um dos objetos pertencentes à lista. 


// tests/CDC/Loja/Carrinho/CarrinhoDeComprasTest.php 


public function testListaDeProdutos() 
{ 
$lista = (new CarrinhoDeCompras ()) 
->adiciona(mew Produto("Jogo de jantar", 200.00, 1)) 
->adiciona(new Produto("Jogo de pratos", 100.00, 1)); 


$this->assertEquals(2, count($lista->getProdutos())); 


$this->assertEquals (200.0, 
$lista->getProdutos() [0]->getValorUnitario()); 
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$this->assertEquals(100.0, 
$lista->getProdutos () [1] ->getValorUnitario()); 


// asserts nos outros atributos, como quantidade, 
// etc, nos objetos dessa lista 


Repare que às vezes seu método pode devolver uma lista com uma quan- 
tidade grande de elementos, tornando difícil a escrita dos asserts. Tente ao 
máximo montar cenários que facilitem seu teste, ou encontre um subcon- 
junto de elementos nessa lista que garantam que o resto do conjunto estará 
correto e teste apenas esses elementos. 





ANICHE DIZ: MAIS DE UM ASSERT NO TESTE. O QUE ISSO SIG- 
NIFICA? 


Em meu doutorado, pesquiso muito sobre a relação do código de 
testes e a qualidade do código de produção. Em um de meus estudos, 
ainda em andamento, tenho verificado a relação entre a quantidade de 
asserts em um teste e qualidade do código que está sendo testado. 

Apesar de um pouco imaturo, o estudo mostrou que, quando um 
método faz asserts em mais de uma instância de objetos diferentes, o 
código de produção que está sendo testado tende a ser pior (em termos 
de complexidade ciclomática e quantidade de linhas de código) do que 
métodos cujos testes fazem asserts em apenas uma única instância de 
objeto. 

Portanto, isso pode ser mais um feedback que o teste lhe dá: se você 
está fazendo asserts em objetos diferentes no mesmo teste, isso pode ser 
um indício de código problemático. 











6.8 SEPARANDO AS CLASSES DE TESTE 


Uma pergunta importante também é onde guardar as classes de teste. A sug- 
estão é sempre separar as classes de produção das classes de teste comumente 
alocadas nas pastas src e tests respectivamente. 
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Outra questão importante é em qual pacote (namespace) colocar as 
classes de teste. Recomendo que as classes de teste estejam no mesmo 
namespace das classes de produção por questões semânticas. Neste capí- 
tulo, estamos utilizando o namespace Loja como exemplo. Neste caso, 
as classes de produção encontram-se em src/Loja e as classes de testes 
em tests/src/Loja. Apesar de estarem em diretórios distintos, ambas as 
classes, de produção e de testes, fazem parte do mesmo namespace. 


6.9 CONCLUSÃO 


Cuidar dos testes é primordial. Testes de baixa qualidade em algum momento 
atrapalharão a equipe de desenvolvimento. Por esse motivo, todas as boas 
práticas de código que desenvolvedores já usam em seus códigos de produção 
devem ser aplicadas ao código de teste. Test data builders, métodos de inicial- 
ização, reúso de código para evitar repetição, boas asserções etc., garantirão 
facilidade de leitura e evolução desses códigos. 

Além disso, conforme discutido no capítulo anterior, buscaremos nos 
testes pequenas dicas sobre a qualidade do código de produção. Isso será difi- 
cil se o código do teste estiver bagunçado. Ou seja, se o desenvolvedor tenta 
mantê-lo limpo, mas mesmo assim não consegue, há uma grande chance de 
o código de produção ter problemas. 
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TDD ea coesão 


Classes que fazem muita coisa são difíceis de serem mantidas. Ao contrário, 
classes com poucas responsabilidades são mais simples e mais fáceis de serem 
evoluídas. 

Uma classe coesa é justamente aquela que possui apenas uma única re- 
sponsabilidade. Em sistemas orientados a objetos, a ideia é sempre buscar 
por classes coesas. Neste capítulo, discutiremos como TDD nos ajuda a en- 
contrar classes com problemas de coesão e, a partir dessa informação, como 
refatorar o código. 
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71 NOVAMENTE O PROBLEMA DO CÁLCULO DE 
SALÁRIO 


Relembrando o problema, é necessário calcular o salário dos funcionários da 


empresa a partir do seu cargo. Para isso, devemos seguir as seguintes regras: 


e Desenvolvedores possuem 20% de desconto caso seu salário seja maior 
do que R$ 3000,0. Caso contrário, o desconto é de 10%. 


e DBAs e testadores possuem desconto de 25% se seus salários forem 
maiores do que R$ 2500,0. 15%, em caso contrário. 


Já temos alguns testes escritos. Por exemplo, o teste a seguir garante que 
desenvolvedores com salário inferior a R$3000,00 recebam apenas 10% de 
desconto: 


public function 


testCalculoSalarioParaDesenvolvedoresComSalarioAbaixoDoLimite() 


$calculadora = new CalculadoraDeSalario(); 
$desenvolvedor = new Funcionario("Andre", 
1500.0, "desenvolvedor") ; 


$salario = $calculadora->calculaSalario($desenvolvedor) ; 


$this->assertEquals(1500.0 * 0.9, $salario, null, 0.00001); 


A implementação atual, que resolvia o problema da regra de negócios para 
os desenvolvedores, parava aqui: 


public function calculaSalario(Funcionario $funcionario) 
{ 
if ( $funcionario->getSalario() > 3000 ) { 
return $funcionario->getSalario() * 0.8; 


} 


return $funcionario->getSalario() * 0.9; 
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O problema começa a aparecer quando testamos um cargo diferente de 
desenvolvedor. Por exemplo, os testes a seguir validam o comportamento da 
classe para DBAs: 


public function 
testDeveCalcularSalarioParaDBAsComSalarioAbaixoDoLimite() 


{ 
$calculadora = new CalculadoraDeSalario(); 
$dba = new Funcionario("Mauricio", 1500.00, "dba"); 
$salario = $calculadora->calculaSalario($dba) ; 
$this->assertEquals(1500.00 * 0.85, $salario, null, 0.00001); 
} 


public function 
testDeveCalcularSalarioParaDBAsComSalarioAcimaDoLimite() 


{ 
$calculadora = new CalculadoraDeSalario(); 
$dba = new Funcionario("Mauricio", 4500.00, "dba"); 
$salario = $calculadora->calculaSalario($dba) ; 
$this->assertEquals(4500.00 * 0.75, $salario, null, 0.00001); 
} 


Para fazê-los passar, é necessário algum condicional no código de pro- 
dução para diferenciar o cálculo de desenvolvedores e DBAs, afinal as regras 
são diferentes. A implementação que segue, por exemplo, resolve o problema 
e faz todos os testes passarem: 


public function calculaSalario(Funcionario $funcionario) 
{ 


if( $funcionario->getCargo() === "desenvolvedor" ) { 


if ( $funcionario->getSalario() > 3000 ) 1 
return $funcionario->getSalario() * 0.8; 


} 


return $funcionario->getSalario() * 0.9; 
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} else if( $funcionario->getCargo() === "dba" ) { 


if( $funcionario->getSalario() < 2500.0 ) { 
return $funcionario->getSalario() * 0.85; 


} 


return $funcionario->getSalario() * 0.75; 


throw new \RuntimeException("Tipo de funcionário inválido"); 


A implementação dos testes para o cargo de testador é bem similar. Basta 
garantir o comportamento do sistema para funcionários que recebem acima 
e abaixo do limite. O código de produção também terá uma solução parecida. 
Basta adicionar um novo “if” para o cargo específico e a implementação será 
finalizada. 


A implementação final seria algo do tipo: 


public function calculaSalario(Funcionario $funcionario) 
{ 


if ($funcionario->getCargo() === "desenvolvedor") { 


if ($funcionario->getSalario() > 3000) { 
return $funcionario->getSalario() * 0.8; 


F 
return $funcionario->getSalario() * 0.9; 
} else if ($funcionario->getCargo() === "dba" || 


$funcionario->getCargo() === "testador") { 
if ($funcionario->getSalario() < 2500.0) { 
return $funcionario->getSalario() * 0.85; 


} 


return $funcionario->getSalario() * 0.75; 


throw new \RuntimeException("Tipo de funcionário inválido"); 
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Como o código está um pouco extenso, é possível refatorá-lo, extraindo 
algumas dessas linhas para métodos privados. Por exemplo: 


namespace CDC\Loja\RH; 
use CDC\Loja\RH\Funcionario; 


class CalculadoraDeSalario 


{ 
public function calculaSalario(Funcionario $funcionario) 
{ 


if ($funcionario->getCargo() === "desenvolvedor") { 


return $this->dezOuVintePorCentoDeDesconto( 


$funcionario) ; 
+ else if ($funcionario->getCargo() === "dba" | | 
$funcionario->getCargo() === "testador") { 
return 


$this->quinzeDuVinteECincoPorCentoDeDesconto ( 
$funcionario) ; 


throw new \RuntimeException( 
"Tipo de funcionário inválido"); 


private function 
dezOuVintePorCentoDeDesconto(Funcionario $funcionario) 


{ 
if ($funcionario->getSalario() > 3000) { 
return $funcionario->getSalario() * 0.8; 
} 
return $funcionario->getSalario() * 0.9; 
} 


private function 
quinzeQuVinteECincoPorCentoDeDesconto( 
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Funcionario $funcionario) 


{ 
if ($funcionario->getSalario() < 2500) { 
return $funcionario->getSalario() * 0.85; 
} 
return $funcionario->getSalario() * 0.75; 
} 
J 
Excelente. É hora de discutir melhor sobre nosso código de testes e código 
de produção. 





ESCREVER MAIS DE UM TESTE DE UMA SÓ VEZ? 


No código anterior, mostrei diretamente dois métodos de teste de 
uma só vez. A pergunta é: você deve fazer isso? Afinal, isso não é TDD. 

Nesse momento, minha sugestão é para que você escreva teste a teste, 
veja cada um falhar, e faça cada um passar na hora certa. Apenas por 
questões de didática e facilidade de leitura, colei ambos de uma só vez. 

Mais para frente, discutiremos sobre quando ou não usar TDD. 











7.2 OUVINDO O FEEDBACK DOS TESTES 


Todos os testes passam e a implementação resolve o problema atual. Mas será 
que o código está simples e fácil de ser mantido? O código de produção nesse 
momento possui alguns problemas graves em termos de evolução. 

O primeiro deles é a complexidade. Veja que, com apenas 2 cargos im- 
plementados, escrevemos 2 ifs, com outros ifs dentro deles. Quanto 
maior a quantidade de condicionais, mais complexo o código fica. Essa com- 
plexidade, aliás, tem um nome: complexidade ciclomática [36]. Complexi- 
dade ciclomática, de maneira simplificada, é o número de diferentes camin- 
hos que seu método pode executar. Por exemplo, quando adicionamos um 
if no código, automaticamente geramos dois diferentes caminhos: um onde 
a condição do if é verdadeiro, e outro caminho onde a condição é falsa. 
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Quanto maior a combinação de ifs, fors, e coisas do gênero, maior será 
esse número. Portanto, do ponto de vista de implementação, esse código é 
bastante complexo. 

Agora, do ponto de vista de design, o código atual apresenta um prob- 
lema ainda pior: sempre que criarmos um novo cargo no sistema (e isso 
é razoavelmente simples, basta adicionar um novo item no construtor de 
Funcionario), é necessário fazer essa alteração também na calculadora de 
salário. Em um sistema real, essas “dependências implícitas” são geralmente 
uma das causas de sistemas apresentarem constantes problemas, pois o de- 
senvolvedor nunca sabe em quais classes ele precisa mexer para propagar uma 
nova regra de negócio. Imagine que, a cada novo cargo criado, o desenvolve- 
dor precisasse atualizar outras 20 classes? Em algum momento ele esqueceria, 
afinal nada o “força” a fazer essa alteração. Códigos frágeis como esse são co- 
muns em implementações geralmente procedurais. 

Mas o teste, de certa, já estava avisando sobre esses problemas. Veja a 
bateria atual de testes: 


testCalculoSalarioParaDesenvolvedoresComSalarioAbaixoDoLimite() 
testCalculoSalarioParaDesenvolvedoresComSalarioAcimaDoLimite() 
testDeveCalcularSalarioParaDBAsComSalarioAbaixoDoLimite() 
testDeveCalcularSalarioParaDBAsComSalarioAcimaDoLimite() 
testDeveCalcularSalarioParaTestadoresComSalarioAbaixoDoLimite() 
testDeveCalcularSalarioParaTestadoresComSalarioAcimaDoLimite() 


Repare que essa bateria de testes tende a ser infinita. Quanto mais cargos 
aparecerem, mais testes serão criados nessa classe. Se a classe de testes possui 
muitos testes, isso quer dizer que a classe de produção possui muitas respon- 
sabilidades. E, em sistemas orientados a objetos, sabemos que classes devem 
ser coesas, conter apenas uma única responsabilidade. Essa classe tende a ter 
milhares de responsabilidades. Quando uma classe de testes tende a crescer 
indefinidamente, isso pode ser um sinal de má coesão na classe de produção. 

Além disso, repare no nome dos testes: deve calcular salário para de- 
senvolvedores com salario abaixo do limite. Repare que esse “para desen- 
volvedores” indica que o comportamento da classe muda de acordo com uma 
característica do objeto que o método recebe como parâmetro (no caso, o 
cargo do funcionário). Isso nos leva a crer que todo novo cargo precisará de 
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um novo teste para o cargo novo. Qualquer variação dessa no nome do teste, 
(“para X” “se X”, “como X” etc.) pode indicar um problema na abstração dessa 
classe. Em um bom sistema orientado a objetos, os comportamentos evoluem 
naturalmente, geralmente por meio da criação de novas classes, e não pela al- 
teração das classes já existentes. 

Ou seja, ao bater o olho no código de testes, temos duas maneiras baratas 
de encontrar problemas na classe de produção: classes de teste que não param 
de crescer e nomes de testes que evidenciam a falta de uma abstração melhor 
para o problema. O trabalho do desenvolvedor nesse momento é entender 
por que isso está acontecendo, e eventualmente refatorar a classe de produção 
para resolver esse problema. 





COMPLEXIDADE CICLOMÁTICA E QUANTIDADE DE TESTES 


Já que a complexidade ciclomática nos diz a quantidade de diferentes 
caminhos que um método tem, e já que sabemos que devemos testar to- 
dos os diferentes comportamentos do nosso método, é possível inferir 
que a complexidade ciclomática tem uma relação direta com a quanti- 
dade de testes de um método. 

Ou seja, quanto maior a complexidade ciclomática, maior a quanti- 
dade de testes necessários para garantir seu comportamento. Portanto, 
um código com alta complexidade ciclomática, além de ser confuso, 
ainda exige um alto esforço para ser testado. 











7.3 TESTES EM MÉTODOS PRIVADOS? 





Veja agora o método quinzeOuVinteECincoPorCentoDeDesconto (). 
Ele é responsável por calcular quinze ou vinte e cinco por cento de desconto 
de acordo com o salário do funcionário. Um método não complicado, mas 
que possui sim alguma regra de negócio envolvida. É necessário testá-lo. A 
pergunta é como fazer para testá-lo, afinal ele é um método privado, o que o 
impossibilita de ser invocado diretamente por um teste. 

Uma discussão grande em torno da comunidade de software é justamente 
sobre a necessidade de se testar métodos privados [6]. Alguns desenvolve- 
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dores acreditam que métodos como esse devem ser testados, e optam por 
fazer uso de frameworks que possibilitam a escrita de testes para métodos 
privados (através de uso de reflection, o framework consegue invocar esse 
método). Outros acreditam que você não deve testá-lo diretamente, mas sim 
indiretamente, através de um método público que faz uso. No caso, igual 
feito nos testes anteriores (o método calculaSalario () invoca o método 





quinzeOuVinteECincoPorCentoDeDesconto ()). 

Novamente, temos a discussão sobre o feedback que o teste dá ao desen- 
volvedor. Se o desenvolvedor sente a necessidade de testar um método 
privado de maneira isolada, direta, ou seja, sem passar por um método 
público que faz uso dele, muito provavelmente é porque esse método pri- 
vado faz muita coisa. 

Métodos privados são geralmente subdivisões de um método público 
maior. Optamos por eles para facilitar a leitura desse método público. Mas 
muitas vezes criamos métodos privados que trabalham demais e possuem 
uma responsabilidade tão bem definida que poderia constituir uma nova 
classe. 

Ao perceber isso, o desenvolvedor deve se perguntar se o método está 
realmente no lugar certo. Talvez faça sentido movê-lo para alguma outra 
classe, ou até mesmo criar uma nova, justamente para acomodar esse com- 
portamento. 

Portanto, evite testar métodos privados. Leve isso como um feedback so- 
bre a qualidade da sua classe. Extraia esse comportamento para uma nova 
classe ou mova-o para uma classe já existente. Transforme-o em um método 


público que faça sentido e, aí, teste-o decentemente. 


7.4 RESOLVENDO O PROBLEMA DA CALCULADORA DE 
SALÁRIO 


Sempre que houver uma separação dos comportamentos em várias pequenas 
classes, com o objetivo de torná-las mais coesas, é necessário uni-las nova- 
mente para se obter o comportamento maior, esperado. 

Para fazer isso de maneira elegante, é preciso algum conhecimento em 
orientação a objetos. Muitos padrões de projeto [20], por exemplo, têm como 
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objetivo unir, de maneira clara, classes que precisam trabalhar juntas. 

Para essa nova questão, podemos começar por resolver o problema dos 
métodos privados. Vamos extraí-los para classes específicas, cada uma re- 
sponsável por uma regra. Como elas são semelhantes, ambas classes im- 
plementarão a mesma interface RegraDeCalculo. Essa implementação se 
parece com o padrão de projeto Strategy: 


namespace CDC\Loja\RH; 
use CDC\Loja\RH\Funcionario; 


interface RegraDeCalculo 


{ 

public function calcula(Funcionario $funcionario); 
} 
O == // 


namespace CDC\Loja\RH; 


use CDC\Loja\RH\RegraDeCalculo, 
CDC\Loja\RH\Funcionario; 


class DezOuVintePorCento implements RegraDeCalculo 
{ 
public function calcula(Funcionario $funcionario) 


{ 
if( $funcionario->getSalario() > 3000 ) { 
return $funcionario->getSalario() * 0.8; 


} 


return $funcionario->getSalario() * 0.9; 


namespace CDC\Loja\RH; 
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use CDC\Loja\RH\RegraDeCalculo, 
CDC\Loja\RH\Funcionario; 


class QuinzeOuVinteECincoPorCento implements RegraDeCalculo 


{ 


public function calcula(Funcionario $funcionario) 


{ 
if( $funcionario->getSalario() < 2500 ) { 
return $funcionario->getSalario() * 0.85; 


} 


return $funcionario->getSalario() * 0.75; 


Repare que cada regra de calculo agora esta em sua classe especifica, bem 
definida. Testar essa classe agora é facil. Teremos 2 ou 3 testes e pronto. Difer- 
entemente da antiga classe CalculadoraDeSalario, as baterias de ambas 
as regras de cálculo não tendem a crescer infinitamente. Isso nos mostra que 
essas classes são razoavelmente coesas. 

Agora, para forçar o desenvolvedor a sempre definir uma regra de cálculo 
para todo e qualquer novo cargo, podemos forçá-lo a decidir isso em uma 
classe própria para a enumeração de Cargo. Faremos todo cargo conter uma 
regra de cálculo: 


namespace CDC\Loja\RH; 


class Cargo 
{ 
private $cargos = array( 
"desenvolvedor" => "CDC\Loja\RH\DezOuVintePorCento", 
"dba" => "CDC\Loja\RH\QuinzeOuVinteECincoPorCento", 
"testador" => "CDC\Loja\RH\QuinzeOuVinteECincoPorCento" 
Já 
private $regra; 


public function | construct($regra) 
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{ 
if( array_key_exists($regra, $this->cargos) ) { 
$this->regra = $this->cargos[$regral] ; 
} else { 
throw new \RuntimeException("Cargo inválido"); 
} 
E; 


public function getRegra() 
{ 


return new $this->regra(); 


Por fim, com todas as responsabilidades bem definidas, a classe 
CalculadoraDeSalario agora ficara bem mais simples. Veja: 


namespace CDC\Loja\RH; 


use CDC\Loja\RH\Cargo, 
CDC\Loja\RH\Funcionario; 


class CalculadoraDeSalario 


{ 
public function calculaSalario(Funcionario $funcionario) 
{ 
$cargo = new Cargo($funcionario->getCargo()); 
return $cargo->getRegra()->calcula($funcionario) ; 
} 
} 


Ela somente repassa a chamada para a regra de cálculo. Nosso código 
agora está muito mais orientado a objetos. Se um novo cargo aparecer, pre- 
cisamos apenas adicionar no construtor da classe Cargos. Se uma nova regra 
de cálculo aparecer, basta criarmos uma nova classe que implementa a inter- 
face certa. Todas as classes são pequenas e fáceis de serem testadas. Nosso 
sistema evolui facilmente e todo código escrito é simples. 
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PRECISO TESTAR A CLASSE CALCULADORA DESALARIO? 


A calculadora de salário agora contém apenas duas linhas, uma que 
instancia os cargos passando em seu construtor o cargo atual do fun- 
cionário, e a outra que repassa para a regra fazer o cálculo. 

Talvez essa classe não precise nem existir mais no sistema. Mas, caso 
exista, talvez não seja necessário testá-la. O teste só garantiria a delegação 
para a regra específica. Se um dia a calculadora ficar mais complexa, aí 
sim testes farão mais sentido para ela. 











Ferreira fala 


A refatoração do código de exemplo da calculadora de salário demon- 
strou muito bem como a atenção à coesão nos leva a um design melhor das 
nossas classes. Será que podemos ir além? Outro mau cheiro no código é a 
repetição, no caso, da lógica de decisão a respeito do desconto a ser aplicado. 
Observamos que os métodos calcula () das duas implementações de re- 
gra de cálculo são muito similares. Podemos abstrair essa lógica fazendo da 
RegraDeCalculo uma classe abstrata: 


namespace CDC\Loja\RH; 
use CDC\Loja\RH\Funcionario; 


abstract class RegraDeCalculo 
{ 
public function calcula(Funcionario $funcionario) 


{ 
$salario = $funcionario->getSalario(); 
if( $salario > $this->limite() ) { 
return $salario * $this->porcentagemAcimaDoLimite() ; 


} 


return $salario * $this->porcentagemBase() ; 


protected function limite() {} 
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protected function porcentagemAcimaDoLimite() {} 
protected function porcentagemBase() {} 
Vamos também modificar as implementações para definirem concreta- 


mente os métodos que estabelecem os parâmetros específicos. Por exemplo, 
aclasse DezOuVintePorCento ficaria: 


namespace CDC\Loja\RH; 
use CDC\Loja\RH\RegraDeCalculo; 


class DezOuVintePorCento extends RegraDeCalculo 


{ 
protected function porcentagemBase() 
{ 
return 0.9; 
E 
protected function porcentagemAcimaDoLimite() 
{ 
return 0.8; 
F 
protected function limite() 
{ 
return 3000; 
} 
E; 





O mesmo fazemos para a classe QuinzeOuVinteECincoPorCento: 


namespace CDC\Loja\RH; 


use CDC\Loja\RH\RegraDeCalculo; 
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class QuinzeOuVinteECincoPorCento extends RegraDeCalculo 


{ 


protected function porcentagemBase() 
{ 


return 0.85; 


protected function porcentagemAcimaDoLimite() 
{ 


return 0.75; 


protected function limite() 


{ 
return 2500; 


Assim eliminariamos a duplicação; esse tipo de estrutura é chamada de 
Template Method. Mas será mesmo que o design ficou melhor? Não existe 
uma resposta fácil a essa pergunta, é um trade-off entre flexibilidade e ab- 
stração, mas na minha opinião eu diria que não, que nesse caso o nível de 
abstração obtido não vale o custo. 


7.5 O QUE OLHAR NO TESTE EM RELAÇÃO A COESÃO? 


Como visto anteriormente, os testes podem nos avisar sobre problemas de co- 
esão em nossas classes. Lembre-se que classes não coesas fazem muita coisa; 
testar “muita coisa” não é fácil. Escrever testes deve ser uma tarefa fácil. 

Quando um único método necessita de diversos testes para garantir seu 
comportamento, o método em questão provavelmente é complexo e/ou pos- 
sui diversas responsabilidades. Códigos assim possuem geralmente diversos 
caminhos diferentes e tendem a alterar muitos atributos internos do objeto, 
obrigando o desenvolvedor a criar muitos testes, caso queira ter uma alta 
cobertura de testes. A esse padrão, dei o nome de Muitos Testes Para Um 
Método. 
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Também pode ser entendido quando o desenvolvedor escreve muitos 
testes para a classe como um todo. Classes que expõem muitos métodos para 
o mundo de fora também tendem a possuir muitas responsabilidades. Chamo 
esse padrão de Muitos Testes Para Uma Classe. 

Outro problema de coesão pode ser encontrado quando o programador 
sente a necessidade de escrever cenários de teste muito grandes para uma 
única classe ou método. É possível inferir que essa necessidade surge em códi- 
gos que lidam com muitos objetos e fazem muita coisa. Nomeei esse padrão 
de Cenário Muito Grande. 

A vontade de testar um método privado também pode ser considerada 
um indício de problemas de coesão. Métodos privados geralmente servem 
para transformar o método público em algo mais fácil de ler. Ao desejar testá- 
lo de maneira isolada, o programador pode ter encontrado um método que 
possua uma responsabilidade suficiente para ser alocada em uma outra classe. 
A esse padrão, chamo de Testes em Método Que Não É Público. 

Lembre-se que esses padrões não dão qualquer certeza sobre o problema. 
Eles são apenas indícios. O programador, ao encontrar um deles, deve visi- 
tar o código de produção e realmente comprovar se existe um problema de 
coesão. De maneira mais geral, tenha em mente que qualquer dificuldade na 
escrita de um cenário ou o trabalho excessivo para se criar cenários para testar 
uma única classe ou método pode indicar problemas de coesão. 

Classes devem ser simples. E classes simples são testadas de forma sim- 
ples. A relação entre código de produção e código de teste é realmente forte. 
A busca pela simplicidade no teste nos leva ao encontro de um código de pro- 
dução mais simples. E assim deve ser. 


7.6 CONCLUSÃO 


Os testes podem nos dar dicas boas e baratas sobre o nível de coesão das nos- 
sas classes. Obviamente, você, desenvolvedor, deve estar atento a isso e mel- 
horar o código de acordo. 

Mas lembre-se que essas dicas são apenas heurísticas para problemas de 
coesão. Não é possível garantir que, toda vez que você se deparar com uma 
classe com muitos testes, ela apresente problemas de coesão. Como tudo em 
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engenharia de software, tudo depende de um contexto. Ou seja, mesmo com 
esses pequenos padrões, não conseguimos tirar o lado criativo e racional do 
desenvolvedor. Você deve avaliar caso a caso. 
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CAPITULO 8 


TDD e o acoplamento 


No capítulo anterior, discutimos a relação entre a prática de TDD e classes 
coesas. Agora é necessário olhar o outro lado da balança: o acoplamento. 
Dizemos que uma classe está acoplada a outra quando existe alguma relação 
de dependência entre elas. Por exemplo, em nosso código anterior, a classe 
Funcionario era acoplada com a classe Cargo. Isso quer dizer que mu- 
danças na enumeração podem impactar a classe de forma negativa. 

Classes altamente coesas e pouco acopladas são difíceis de serem proje- 
tadas. Neste capítulo, discutiremos como TDD ajuda o desenvolvedor a en- 
contrar problemas de acoplamento no seu projeto de classes. 


8.1 O PROBLEMA DA NOTA FISCAL 


O processo de geração de nota fiscal é geralmente complicado. Envolve uma 
série de cálculos de acordo com as diversas características do produto ven- 
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dido. Mas, mais complicado ainda pode ser o fluxo de negócio após a geração 
da nota: enviá-la para um sistema maior, como um SAP, enviar um e-mail 
para o cliente com a nota fiscal gerada, persistir as informações na base de 
dados, e assim por diante. 

De maneira simplificada, uma possível representação da Nota Fiscal e Pe- 
dido pode ser semelhante ao que segue: 


namespace CDC\Loja\FluxoDeCaixa; 


class Pedido 


{ 


private $cliente; 
private $valorTotal; 
private $quantidadeTtens; 


public function __construct($cliente, $valorTotal, 


$quantidadeItens) 
{ 
$this->cliente = $cliente; 
$this->valorTotal = $valorTotal; 
$this->quantidadeItens = $quantidadeItens; 
} 


public function getCliente() 


{ 
return $this->cliente; 
} 
public function getValorTotal() 
{ 
return $this->valorTotal; 
} 
public function getQuantidadeItens() 
{ 
return $this->quantidadeItens; 
} 
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namespace CDC\Loja\FluxoDeCaixa; 


class NotaFiscal 


{ 

private $cliente; 

private $valor; 

private $data; 

public function __construct($cliente, $valor, $data) 

{ 
$this->cliente = $cliente; 
$this->valor = $valor; 
$this->data = $data; 

} 

public function getCliente() 

{ 
return $this->cliente; 

} 

public function getValor() 

{ 
return $this->valor; 

} 

public function getData() 

{ 
return $this->data; 

} 

} 


Imagine que hoje esse processo consiste em gerar a nota, persistir no 
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banco de dados e enviá-la por e-mail. No capítulo passado, discutimos sobre 
coesão e classes com responsabilidades específicas. Para o problema proposto, 
precisamos de 3 diferentes classes: uma responsável por enviar o e-mail, outra 
responsável por persistir as informações na base de dados, e por fim, uma 
classe responsável pelo cálculo do valor da nota fiscal. 

Para facilitar o entendimento do exemplo, a implementação das classes 
que se comunicam com o banco de dados e com o SAP serão simplificadas. 
Veja o código a seguir: 


class SAP 
{ 
public function envia(NotaFiscal $nf) 
{ 
// envia NF para o SAP 
} 


class NFDao 


{ 
public function persiste(NotaFiscal $nf) 
{ 
// persiste NF 
} 
} 


Agora é possível iniciar a escrita da classe GeradorDeNotaFiscal, re- 
sponsável por calcular o valor final da nota e, em seguida, disparar a sequência 
do processo de negócio. 

Imagine que a regra para cálculo da nota fiscal seja simples: o valor da 
nota deve ser o valor do produto subtraído de 6%. Ou seja, 94% do valor total. 
Esse é um problema parecido com os anteriores. Começando pelo teste: 


namespace CDC\Loja\FluxoDeCaixa; 


use CDC\Loja\Test\TestCase, 
CDC\Loja\FluxoDeCaixa\GeradorDeNotaFiscal; 
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class GeradorDeNotaFiscalTest extends TestCase 


{ 
public function testDeveGerarNFComValorDeImpostoDescontado() 
{ 
$gerador = new GeradorDeNotaFiscal(); 
$pedido = new Pedido("Andre", 1000, 1); 
$nf = $gerador->gera($pedido) ; 
$this->assertEquals(1000 * 0.94, $nf->getValor(), 
null, 0.00001); 
} 
} 


Fazer o teste passar é trivial. Basta instanciarmos uma nota fiscal com 6% 
do valor a menos do valor do pedido. Além disso, a data da nota fiscal sera a 
data de hoje: 


namespace CDC\Loja\FluxoDeCaixa; 


use CDC\Loja\FluxoDeCaixa\Pedido; 
use DateTime; 


class GeradorDeNotaFiscal 


{ 
public function gera(Pedido $pedido) 
{ 
return new NotaFiscal( 
$pedido->getCliente(), 
$pedido->getValorTotal() * 0.94, 
new DateTime() 
); 
} 
} 


O teste passa. O próximo passo é persistir essa nota fiscal. A classe NFDao 
já existe. Basta fazermos uso dela. Dessa vez, sem escrever o teste antes, vamos 
ver como ficaria a implementação final: 
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namespace CDC\Loja\FluxoDeCaixa; 


use CDC\Loja\FluxoDeCaixa\Pedido; 
use DateTime; 


class GeradorDeNotaFiscal 
{ 
public function gera(Pedido $pedido) 


{ 
$nf = new NotaFiscal ( 
$pedido->getCliente() , 
$pedido->getValorTotal() * 0.94, 
new DateTime() 


3 


$nfDao = new NFDao(); 
if( $nfDao->persiste($nf) ) { 
return $nf; 


} 


return null; 


A grande pergunta agora é: como testar esse comportamento? Acessar 
o banco de dados e garantir que o dado foi persistido? Não parece uma boa 
ideia. 


8.2 Mock OBJECTS 


A ideia de um teste de unidade é realmente testar a classe de maneira isolada, 
sem qualquer interferéncia das classes que a rodeiam. A vantagem desse iso- 
lamento é conseguir um maior feedback do teste em relação à classe sob teste; 
em um teste em que as classes estão integradas, se o teste falha, qual classe 
gerou o problema? 

Além disso, testar classes integradas pode ser difícil para o desenvolvedor. 
Em nosso exemplo, como garantir que o elemento foi realmente persistido? 
Seria necessário fazer uma consulta posterior ao banco de dados, garantir 
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que a linha está lá, limpar a tabela para que, na próxima vez que o teste for 
executado, os dados já existentes na tabela não atrapalhem o teste, e assim por 
diante. 

É muito trabalho. E, na verdade, razoavelmente desnecessário. Persis- 
tir o dado no banco de dados é tarefa da classe NFDao. A tarefa da classe 
GeradorDeNotaFiscal é somente invocar o DAO. Não há motivo para os 
testes da GeradorDeNotaFiscalTest garantirem que o dado foi persis- 
tido com sucesso; isso seria tarefa da classe NFDaoTest. 

Nesse caso, uma alternativa seria simular o comportamento do NFDao 
no momento do teste do gerador de nota fiscal. Ou seja, queremos criar um 
clone de NFDao que “finja” o acesso ao banco de dados. Classes que simulam o 
comportamento de outras são chamadas de mock objects, ou objetos dublês. 

Um framework de mock facilita a vida do desenvolvedor que deseja criar 
classes falsas para seus testes. Um mock pode ser bem inteligente. É possível 
ensinar o mock a reagir da maneira que queremos quando um método for 
invocado, descobrir a quantidade de vezes que o método foi invocado pela 
classe de produção, e assim por diante. 

No caso de nosso exemplo, precisamos garantir que o método 
NFDao->persiste () foi invocado pela classe GeradorDeNotaFiscal. 
Nosso teste deve criar o mock e garantir que o método esperado foi invocado. 

Aqui utilizaremos o framework conhecido como Mockery [34]. Com ele, 
criar mocks e validar o esperado é fácil. Sua API é bem simples e fluente. 
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DE VOLTA AO COMPOSER 


Lembrando um pouco do que foi apresentado no capítulo 2 precisare- 
mos agora adicionar mais uma biblioteca em nosso arquivo de definição 
do Composer ( composer. json), o framework Mockery. 


"require-dev" : { 
“phpunit/phpunit" : "4.*", 
"mockery/mockery" : "x" 

+, 


Perceba que o adicionamos na seção require-dev pois ele não 
será necessário em ambiente de produção, somente no ambiente de de- 
senvolvimento. Após declarada a necessidade de utilização do Mock- 
ery basta atualizar os pacotes gerenciados pelo Composer através 
do comando php composer.phar update em seu terminal. Os 
dois comandos básicos do Composer a serem utilizados são php 
composer.phar install, quando você está inicializando o seu pro- 
jeto,e php composer.phar update, quando já está com seu projeto 
em andamento e adiciona uma nova dependência, que foi o nosso caso. 











Tudo pronto para utilizarmos o Mockery. 
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POR QUE O FRAMEWORK MOCKERY? 


Talvez você não saiba, mas o proprio PHPUnit tem a capacidade de 
criar Mocks. No entanto, para que os exemplos sejam mais simplistas, 
utilizaremos o framework Mockery. O Mockery possui uma interface 
muito facil de ser utilizada, com chamadas a métodos de forma seman- 
tica. Note no próximo exemplo a diferença entre um objeto mockado 
com o padrão do PHPUnit e o mesmo objeto com o Mockery. 


// Padrão do PHPUnit 
$nfDao = $this->getMock ("NFDao", array("persiste")); 
$nfDao->expects ($this->once() ) 

->method ("persiste") 

->with ($this->returnValue(true)); 


// Com o Mockery 
$nfDao = Mockery: :mock("NFDao"); 
$nfDao->shouldReceive("persiste")->andReturn (true); 


Perceba que ambos fazem exatamente a mesma coisa mas claramente 
vemos como o Mockery simplifica nossa vida. É só informar o método 
que queremos utilizar, neste caso o persiste, e qual o valor que ele 
deve simular de retorno do método. 











Perfeito, agora temos o Mockery instalado em nossa aplicação. Para 
utilizá-lo, o caminho mais simples é seguir o conceito de injeção de dependên- 
cia que será basicamente descrito mais à frente. 

Veja o teste a seguir, no qual criamos o mock e depois validamos que o 
método foi invocado: 


public function testDevePersistirNFGerada() 


{ 
$dao = Mockery: :mock("CDC\Loja\FluxoDeCaixa\NFDao") ; 
$dao->shouldReceive("persiste") ->andReturn (true) ; 


$gerador = new GeradorDeNotaFiscal() ; 
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$pedido = new Pedido("Andre", 1000, 1); 
$nf = $gerador->gera($pedido) ; 


$this->assertTrue($dao->persiste()); 
$this->assertNotNull ($nf) ; 


O problema é que, se rodarmos o teste, ele falha. Isso acontece porque, 
apesar de termos criado o mock, o GeradorDeNotaFiscal não faz uso 
dele. Repare que, na implementação, ele instancia um NFDao. É necessário 
que o gerador seja mais esperto: ele deve usar o mock no momento do teste, 
e a classe NFDao quando o código estiver em produção. 

Uma solução para isso é receber a classe pelo construtor. Dessa forma, é 
possível passar o mock ou a classe concreta. Em seguida, fazer uso do DAO 
recebido: 


namespace CDC\Loja\FluxoDeCaixa; 


use CDC\Loja\FluxoDeCaixa\Pedido, 
CDC\Loja\FluxoDeCaixa\NFDao; 
use DateTime; 


class GeradorDeNotaFiscal 


{ 
private $dao; 


public function __construct(NFDao $dao) 


{ 
$this->dao = $dao; 


public function gera(Pedido $pedido) 
{ 
$nf = new NotaFiscal ( 
$pedido->getCliente(), 
$pedido->getValorTotal() * 0.94, 
new DateTime() 
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if( $this->dao->persiste($nf) ) { 
return $nf; 


} 


return null; 


Agora, basta passar o mock para a classe sob teste e o comportamento do 
DAO será simulado: 


public function testDevePersistirNFGerada() 


{ 
$dao = Mockery: :mock("CDC\Loja\FluxoDeCaixa\NFDao") ; 
$dao->shouldReceive("persiste") ->andReturn (true) ; 


$gerador = new GeradorDeNotaFiscal ($dao) ; 
$pedido = new Pedido("Andre", 1000, 1); 


$nf = $gerador->gera($pedido) ; 


$this->assertTrue($dao->persiste()); 
$this->assertEquals(1000 * 0.94, 
$nf->getValor(), null, 0.00001); 


Podemos fazer a mesma coisa com os próximos passos da geração da nota 
fiscal, como enviar para o SAP, enviar por e-mail etc. Basta passar mais uma 
dependência pelo construtor, criar outro mock e garantir que o método foi 
enviado. Com o SAB por exemplo: 


public function testDeveEnviarNFGeradaParaSAP() 


{ 
$dao = Mockery: :mock("CDC\Loja\FluxoDeCaixa\NFDao") ; 
$dao->shouldReceive("persiste") ->andReturn (true) ; 


$sap = Mockery: :mock("CDC\Loja\FluxoDeCaixa\SAP") ; 
$sap->shouldReceive("envia") ->andReturn (true); 
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$gerador = new GeradorDeNotaFiscal ($dao, $sap); 
$pedido = new Pedido("Andre", 1000, 1); 


$nf = $gerador->gera($pedido) ; 


$this->assertTrue($sap->envia()); 
$this->assertEquals (1000 * 0.94, 
$nf->getValor(), null, 0.00001); 


namespace CDC\Loja\FluxoDeCaixa; 


use CDC\Loja\FluxoDeCaixa\Pedido, 
CDC\Loja\FluxoDeCaixa\NFDao, 
CDC\Loja\FluxoDeCaixa\SAP; 
use DateTime; 


class GeradorDeNotaFiscal 


{ 


private $dao; 
private $sap; 


public function 


{ 


_construct(NFDao $dao, SAP $sap) 


$this->dao 
$this->sap 


$dao; 
$sap; 


public function gera(Pedido $pedido) 
{ 
$nf = new NotaFiscal ( 
$pedido->getCliente(), 
$pedido->getValorTotal() * 0.94, 
new DateTime () 
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if( $this->dao->persiste($nf) 
&& $this->sap->envia($nf) ) { 
return $nf; 


} 


return null; 





TDD NO ESTILO LONDRINO 


Muitas pessoas conhecem a pratica de TDD e mockar as dependén- 
cias como “TDD ao estilo londrino”, Muitas das discussões importantes 
na área de mock objects surgiram por lá. Famosos autores como Steve 
Freeman e Nat Pryce (ambos britânicos) são fãs dessa abordagem. 

Independente do nome, agrada-me muito a utilização de mock ob- 
jects durante a escrita dos testes. Quando estou criando uma classe, 
mocks me ajudam a pensar somente no que ela vai fazer e como ela vai 
interagir com as outras classes do sistema. Nesse momento, preocupo- 
me muito pouco com as outras classes e foco somente no que espero da 
classe atual. Sem a utilização de mocks, isso seria um pouco mais trabal- 
hoso. 











8.3 DEPENDÊNCIAS EXPLÍCITAS 


Repare que, por uma necessidade do teste, optamos por receber as dependên- 
cias da classe pelo construtor. Isso é, na verdade, uma boa prática quando se 
pensa em orientação a objetos. 

Em primeiro lugar o desenvolvedor deixa as dependências da classe ex- 
plícitas. Basta olhar seu construtor, e ver quais classes são necessárias para que 
ela faça seu trabalho por completo. Em segundo lugar, ao receber a dependên- 
cia pelo construtor, a classe facilita sua extensão. Por meio de polimorfismo, 
o desenvolvedor pode, a qualquer momento, optar por passar alguma classe 
filho da classe que é recebida (ou, no caso de uma interface, outra classe a 
implementa), mudando/evoluindo seu comportamento. 
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Novamente retomo a frase de que um código fácil de ser testado pos- 
sui características interessantes do ponto de vista de design. Explicitar as de- 
pendências é uma necessidade quando se pensar em testes de unidade, afinal 
essa é a única maneira de se passar um mock para a classe. 


8.4 OUVINDO O FEEDBACK DOS TESTES 


A classe GeradorDeNotaFiscal tem um problema grave de evolução. 
Imagine se após a geração da nota houvesse mais 10 atividades para serem ex- 
ecutadas, similares a persistir no banco de dados e enviar para o SAP. A classe 
passaria a receber uma dezena de dependências no construtor, tornando-se 
altamente acoplada. Classes como essas são chamadas de God Classes, pois 
elas geralmente contêm pouca regra de negócio, e apenas coordenam o pro- 
cesso de várias classes juntas. 

Repare que, na prática, essa é a balança tradicional em sistemas orientados 
a objetos. No capítulo anterior, tínhamos uma única classe, pouco acoplada, 
mas que continha todas as regras de negócio dentro dela, tornando-a difícil 
de ser lida e testada. Por fim, optamos por separar os comportamentos em 
pequenas classes. Já neste capítulo, os comportamentos já estão separados, já 
que a classe NFDao contém a lógica de acesso a dados, a classe SAP contém 
a comunicação com o SAP, e assim por diante. Mas é necessário juntar essas 
pequenas classes para realizar o comportamento total esperado e, ao fazermos 
isso, caímos no problema do acoplamento. 

Os testes escritos podem nos dar dicas importantes sobre problemas de 
acoplamento. Um primeiro feedback importante é justamente a quantidade 
de mock objects em um teste. Imagine se nossa classe realmente fizesse uso 
de outras 10 classes; o teste teria 10 mock objects. Apesar da não necessidade 
nesse cenário específico, em muitos testes existe a necessidade de ensinar o 
mock object a reagir de acordo com o esperado. Logo, o teste gastaria muitas 
linhas simplesmente para montar todos os objetos dublês necessários para ele. 

Além disso, o “mau uso” de mock objects pode ser indício de prob- 
lemas com a abstração e o excesso de acoplamento. Veja o teste 





testDeveEnviarNFGeradaParaSAP, por exemplo. Repare que, para esse 
teste, a interação com o dublê do NFDao pouco importa. Ou seja, a classe 
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contém uma dependência que interessa apenas a um subconjunto dos testes, 
mas não para todos eles. Por que isso aconteceria? Provavelmente existe uma 
outra maneira de desenhar isso de forma a melhorar o gerenciamento de de- 
pendências dessa classe e diminuir seu acoplamento. 


8.5 CLASSES ESTÁVEIS 


Uma das conhecidas vantagens do TDD é que ele “diminui o acoplamento”, 
ou “ajuda a diminuir o acoplamento”. A grande pergunta é como ele o faz. 
Suponha o código a seguir, que lê um XML e escreve o conteúdo por uma 
porta serial: 


class Copiadora 


{ 
public function copiar() 
{ 
$leitorXML = new LeitorDeXML() ; 
$escritorSerial = new EscritorPelaSerial(); 
while($leitorXML->temCaracteres()) { 
$escritorSerial->escreve($leitorXML->1eCaracteres()); 
} 
} 


Veja que essa classe é fortemente acoplada com duas classes: 





LeitorDeXMLe EscritorPelaSerial. Se quantificarmos isso, podemos 





dizer que o acoplamento dessa classe é igual a 2 (já que ela está acoplada a 2 
classes). 

Ao praticar TDD para a criação da classe Copiadora, o desenvolvedor 
provavelmente focará primeiramente na classe Copiadora e no que ela deve 
fazer, esquecendo os detalhes da implementação do leitor e do escritor. Para 
conseguir esquecer desses detalhes, o desenvolvedor provavelmente criaria 
interfaces que representariam as ações esperadas de leitura e escrita: 


public function testDeveLerEEnviar0ConteudoLido() 


{ 
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$leitor = Mockery::mock("Leitor''); 
$escritor = Mockery: :mock("Escritor") ; 


$leitor->shouldReceive("temCaracteres") 

->andReturn(true, false); 
$leitor->shouldReceive("leCaracteres") ->andReturn("andre") ; 
$copiadora = new Copiadora($leitor, $escritor) ; 


$copiadora->copiar () ; 


$this->assertEquals("andre", $escritor->escreve("andre")) ; 


} 
interface Leitor 
{ 
public function temCaracteres(); 
public function leCaracteres(); 
E; 
interface Escritor 
{ 
public function escreve($conteudo) ; 
} 


Repare que o teste cria dois mocks, escritor e leitor. Em seguida, 
define o comportamento esperado pelo dublê do leitor: o método 
temCaracteres() deve devolver “verdadeiro” e “falso”, nessa ordem, 
e leCaracteres() devolvendo o texto “mauricio” A seguir, cria a 
Copiadora, passando os dublês, invoca o comportamento sob teste, e por 
fim, verifica que o escritor recebeu a instrução para escrever a palavra esper- 
ada. 

Repare que para esse teste pouco importa como funcionará a classe que 
lê e a classe que escreve. Ao praticar TDD, isso é comum. Preocupamo-nos 
menos com as classes com as quais a classe atual interagirá, e mais apenas com 
a interface que elas devem prover. Não há forma melhor de representar esses 
contratos do que utilizando interfaces. 
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Mas qual a diferença entre ambos os códigos do ponto de vista do acopla- 
mento? Afinal, nas duas implementações, a classe Copiadora continua de- 
pendendo de 2 outras classes (ou interfaces). 

A diferença é em relação à estabilidade da segunda classe [27]. Repare 
que a segunda implementação depende apenas de interfaces e não de classes 
concretas. O real problema do alto acoplamento é que as dependências de 
uma classe podem sofrer mudanças, propagando-as para a classe principal. 
Logo, quanto maior a dependência, mais instável é a classe, ou seja, maior a 
chance de ela sofrer uma mudança. 


3 tale) 





Podem propagar mudanças para a classe principal 


Interfaces, por sua vez, tendem a ser classes que mudam muito pouco por 
várias razões. Primeiro porque elas não contêm detalhes de implementação, 
atributos ou qualquer outra coisa que tenda a mudar. Segundo porque geral- 
mente interfaces possuem diversas implementações embaixo delas e o desen- 
volvedor tende a não alterá-las, pois sabe que se o fizer, precisará alterar em 
todas as implementações. Logo, se interfaces não mudam (ou mudam muito 
pouco), acoplar-se com elas pode não ser tão problemático. 


Veja no exemplo anterior. As classes LeitorDeXML e 





EscritorPelaSerial provavelmente dependem de outras classes (a 





leitora de XML deve fazer uso de alguma biblioteca para tal, bem como a 
que escreve pela serial), possuem atributos e muito código para fazer seu 
serviço. A chance de elas mudarem é alta, portanto, tendem a ser instáveis. 
Ao contrário, as interfaces Leitor e Escritor não dependem de nada, 
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não possuem código e classes as implementam. Logo, são estáveis, o que 
significa que depender delas não é uma ideia tão má. 

Podemos dizer que uma boa dependência é uma dependência com um 
módulo (ou classe) estável, e uma má dependência é uma dependência com 
um módulo (ou classe) instável. Logo, se houver a necessidade de se acoplar 
com alguma outra classe, que seja com uma classe razoavelmente estável. 

TDD faz com que o programador acople suas classes com módulos geral- 
mente mais estáveis! TDD força o desenvolvedor a pensar apenas no que você 
espera das outras classes, sem pensar ainda em uma implementação concreta. 
Esses comportamentos esperados acabam geralmente se transformando em 
interfaces, que frequentemente se tornam estáveis. 


8.6 RESOLVENDO O PROBLEMA DA NOTA FISCAL 


Para gerenciar melhor a dependência da classe GeradorDeNotaFiscal, é 
necessário fazer com que ela dependa de módulos estáveis; uma interface é a 
melhor candidata. Repare que toda ação executada após a geração da nota, 
independente de qual for, precisa receber apenas a nota fiscal gerada para 
fazer seu trabalho. Portanto, é possível criar uma interface para representar 
todas elas e fazer com que SAP, NF Dao ou qualquer outra ação a ser executada 
após a geração da nota, implemente-a: 


namespace CDC\Loja\FluxoDeCaixa; 
use CDC\Loja\FluxoDeCaixa\NotaFiscal; 


interface AcaoAposGerarNotaInterface 
{ 


public function executa(NotaFiscal $nf); 


Veja que AcaoAposGerarNotaInterface tende a ser estável: é uma 
interface e possui algumas classes concretas que a implementa. 

O próximo passo agora é fazer com que o gerador de nota fiscal dependa 
de uma lista dessas ações, e não mais de classes concretas. Uma sugestão é 
receber essa lista pelo construtor, já deixando a dependência explícita: 
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class GeradorDeNotaFiscal 


{ 
private $acoes; 
public function __construct($acoes) 
{ 
$this->acoes = $acoes; 
} 
ae 
} 


Basta agora fazer com que o gerador, após criar a nota, invoque todas as 
ações que estão na lista: 


public function gera(Pedido $pedido) 


{ 
$nf = new NotaFiscal( 
$pedido->getCliente(), 
$pedido->getValorTotal() * 0.94, 
new DateTime() 
5 
foreach($this->acoes as $acao) { 
$acao->executa($nf) ; 
} 
return $nf; 
} 


Repare agora que a classe GeradorDeNotaFiscal não está mais forte- 
mente acoplada a uma ação concreta, mas sim a uma lista qualquer de ações. 
A chance de ela sofrer uma alteração propagada por uma dependência é bem 
menor. Além do mais, a evolução dessa classe passa a ser natural: basta passar 
mais itens na lista de ações, que ela as executará. Não há mais a necessidade 
de alterar a classe para adicionar um novo comportamento. Em orientação 
a objetos, a ideia de estendermos o comportamento de uma classe sem al- 
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terar seu código é conhecido como Princípio do Aberto-Fechado, ou OCP 
(Open-Closed Principle). 





Classes concretas não propagam mais mudanças para classe principal 





Para testarmos, precisamos apenas garantir que as ações da lista, quais- 
quer que sejam, serão executadas pelo gerador: 


public function testDeveInvocarAcoesPosteriores() 
{ 
$acaol = Mockery: :mock( 
"CDCzLoja\FluxoDeCaixa\AcaoAposGerarNotaInterface") ; 
$acao1->shouldReceive("executa") ->andReturn (true); 


$acao2 = Mockery: :mock( 
"CDC\Loja\FluxoDeCaixa\AcaoAposGerarNotalInterface") ; 


$acao2->shouldReceive("executa") ->andReturn (true); 


$gerador = new GeradorDeNotaFiscal(array($acao1, $acao2)); 
$pedido = new Pedido("Andre", 1000, 1); 


$nf = $gerador->gera($pedido) ; 
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$this->assertTrue ($acaol->executa($nf)); 
$this->assertTrue ($acao2->executa($nf)); 
$this->assertNotNull ($nf) ; 
$this->assertInstance0f( 
"CDC\Loja\FluxoDeCaixa\NotaFiscal", $nf); 


Toda essa refatoração, no fim, foi disparada por um feedback do nosso 
teste: o mau uso ou o uso excessivo de mock objects. O teste avisando o 
problema de design, aliado ao conhecimento de orientação a objetos, pro- 
porcionou uma melhoria significativa na classe. 


8.7 TESTANDO MÉTODOS ESTÁTICOS 


Outro tipo de acoplamento, dificil de ser testado, é o acoplamento com méto- 
dos estáticos. Acabamos de ver que, para simular o comportamento das 
classes, é necessário fazer uso de objetos dublês e, de alguma forma, fazer 
com que a classe receba e utilize esses dublês. No caso de métodos estáticos, 
não há como recebê-los pelo construtor. 

Em nosso exemplo, imagine que a data da nota fiscal nunca possa 
ser no fim de semana. Se a nota for gerada no sistema, o sistema 
deve empurrar sua data para segunda-feira. Em PHP, para pegar- 
mos a data atual do sistema, podemos fazer uso do método estático 





DateTime: :createFromFormat (). Como simular seu comportamento 
e escrever um teste para a geração de uma nota fiscal em um sábado? 

Nesses casos, a sugestão é sempre criar uma abstração para facilitar o 
teste. Ou seja, em vez de fazer uso direto do método estático, criar uma 
classe/interface, responsável por devolver a hora atual, e que seja possível de 
ser mockada. Podemos, por exemplo, criar a interface Relogio e a imple- 


mentação concreta RelogioDoSistema: 


namespace CDC\Exemplos; 


interface RelogioInterface 
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public function hoje(); 


namespace CDC\Exemplos; 


use CDC\Exemplos\RelogioInterface; 
use DateTime; 


class RelogioDoSistema implements RelogioInterface 


{ 
public function hoje() 


{ 
return DateTime: :createFromFormat ( 
’Y-m-d’, date(’Y-m-d’)); 
} 
} 
O gerador, por sua vez, passa a fazer uso de um relógio para pegar a data 
atual: 


namespace CDC\Loja\FluxoDeCaixa; 


use CDC\Loja\FluxoDeCaixa\Pedido, 
CDC\Exemplos\RelogioInterface; 


class GeradorDeNotaFiscal 


{ 


private $acoes; 
private $relogio; 


_construct ($acoes, 


public function 
RelogioInterface $relogio) 


$this->acoes = $acoes; 
$this->relogio = $relogio; 
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} 
public function gera(Pedido $pedido) 
{ 
$nf = new NotaFiscal( 
$pedido->getCliente(), 
$pedido->getValorTotal() * 0.94, 
$this->relogio->hoje() 
); 
foreach($this->acoes as $acao) { 
$acao->executa($nf) ; 
} 
return $nf; 
} 


Recebendo esse Relogio pelo construtor, o teste é natural. Basta montar 
o cenário esperado, e verificar a saída do método de acordo com o esperado. 

Métodos estáticos são problemáticos. Além de dificultarem a evolução da 
classe, afinal o desenvolvedor não consegue fazer uso de polimorfismo e fazer 
uso de uma implementação diferente desse método, eles ainda dificultam o 
teste. 

Evite ao máximo criar métodos estáticos. Só o faça quando o método 
for realmente simples. Tente sempre optar por interfaces e implementações 
concretas, fáceis de serem dubladas. Ao lidar com APIs de terceiros, crie ab- 
strações em cima delas única e exclusivamente para facilitar o teste. 

Lembre-se: você pode tomar decisões de design pensando exclusiva- 
mente na testabilidade. Seu código, acima de tudo, deve ser confiável, e para 
isso deve ser testado. 


8.8 TDD E A CONSTANTE CRIAÇÃO DE INTERFACES 


Imagine que o problema do gerador de notas fiscais torne-se um pouco mais 
complicado. Para calcular o valor do imposto, devemos olhar o valor do pe- 
dido. Essa tabela contém uma série de faixas de valor, cada uma com uma 
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porcentagem associada. Por exemplo, valores entre zero e R$999 possuem 2% 
de imposto, valores entre R$1000,00 e R$2999,00 possuem 6% de imposto, e 
assim por diante. Imagine que essa tabela é razoavelmente grande e está ar- 
mazenada em um arquivo XML. O gerenciador, com essa porcentagem em 
mãos, deve apenas multiplicar pelo valor total do pedido. 

Para o gerenciador de nota fiscal, pouco importa como a tabela faz seu 
trabalho, mas sim o valor que ela retorna. A experiência nos diz que a lógica 
responsável por essa tabela deve estar em uma classe separada, e o gerenciador 
deve fazer uso dela. 

Podemos deixar isso explícito no teste, passando uma dependência 
Tabela (que ainda nem existe) para o construtor do gerenciador. Além disso, 
podemos exigir que essa tabela tenha sido consultada pelo gerenciador. O 
Mockery nos ajudará nisso: 


use Loja\DataEhora\RelogioDoSistema; 


PE axed 


public function testDeveConsultarATabelaParaCalcularValor () 
{ 

// mockando uma tabela, que ainda nem existe 

$tabela = Mockery: :mock("CDC\Loja\Tributos\Tabela") ; 


// definindo o futuro comportamento "paraValor", 

// que deve retornar 0.2 caso valor seja 1000.0 

$tabela->shouldReceive("paraValor") 
->with(1000.0)->andReturn (0.2) ; 


$gerador = new GeradorDeNotaFiscal (array(), 
new RelogioDoSistema(), $tabela); 
$pedido = new Pedido("Andre", 1000.0, 1); 


$nf = $gerador->gera($pedido) ; 
//garantindo que a tabela foi consultada 


$this->assertEquals(1000 * 0.2, 
$nf->getValor(), null, 0.00001); 
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Neste momento, o teste não passa, pois não existe a classe Tabela. Pode- 
mos optar por começar a trabalhar nessa classe e deixar o gerenciador de lado. 
Mas se fizermos isso, perderemos o foco. Não importa agora como a tabela 
fará o seu trabalho; mas sabemos exatamente o que esperar dela: uma por- 
centagem de acordo com um valor. 

Podemos definir uma interface para representar esse comportamento que 
será futuramente implementado por alguma classe: 


namespace CDC\Loja\Tributos; 


interface TabelaInterface 
{ 


public function paraValor( $valor ); 


Com essa interface bem definida, podemos fazer o teste passar, recebendo 
a tabela no construtor e fazendo uso dela no método gera (): 


namespace CDC\Loja\FluxoDeCaixa; 


use CDC\Loja\FluxoDeCaixa\Pedido, 
CDC\Exemplos\RelogioInterface, 
CDC\Loja\Tributos\TabelaInterface; 


class GeradorDeNotaFiscal 


{ 


private $acoes; 
private $relogio; 
private $tabela; 


public function __construct($acoes, 


RelogioInterface $relogio, TabelaInterface $tabela) 


{ 
$this->acoes = $acoes; 
$this->relogio = $relogio; 
$this->tabela = $tabela; 

} 
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public function gera(Pedido $pedido) 


{ 
$valorTabela = $this->tabela->paraValor ( 
$pedido->getValorTotal()); 
$valorTotal = $pedido->getValorTotal() * $valorTabela; 


$nf = new NotaFiscal ( 
$pedido->getCliente(), 
$valorTotal, 
$this->relogio->hoje() 
); 


foreach($this->acoes as $acao) { 
$acao->executa($nf); 


return $nf; 


Agora, podemos criar mais testes que fazem uso da tabela, sem na ver- 
dade nos preocuparmos com a implementação, pois já conhecemos seu con- 
trato. Esse tipo de procedimento é muito comum durante a prática de TDD. 
Ao criar classes, percebemos que é necessário dividir o comportamento em 
classes diferentes. Nesse momento, é comum criarmos uma interface para 
representar o comportamento esperado e continuar a criação e testes daquela 
classe sem nos preocuparmos com como cada dependência fará seu trabalho. 

Essa nova maneira de programar ajuda inclusive a criar contratos mais 
simples de serem implementados, afinal as interfaces conterão apenas os com- 
portamentos simples, diretos e necessários para que a classe principal faça seu 
trabalho. Em nosso caso, após acabar a implementação do gerador, o próx- 
imo passo seria criar a classe TabelaDoGoverno, por exemplo, que imple- 
menta a interface Tabela e descobre a porcentagem de acordo com a faixa 
de valores. Talvez essa classe precise fazer uso de alguma outra classe. Não 
há problema: criaríamos novamente uma outra interface para representar o 


comportamento esperado e continuariamos a trabalhar na tabela. 


Portanto, ao praticar TDD, o programador foca apenas no que ele precisa 
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das outras classes. Isso faz com ele crie contratos estáveis e simples de serem 
implementados. Veja novamente como o teste e o foco nele fizeram com que 
pensássemos no projeto de classes. 





ESTILO LONDRINO NA PRÁTICA 


É assim que funciona o estilo londrino de TDD. As interfaces vão 
emergindo à medida que são necessárias. Os testes acabam por deixar 
explícito como funciona a interação entre essas várias classes. 

Nesse momento, o uso de mock objects torna-se fundamental para 
facilitar o teste. 











8.9 O QUE OLHAR NO TESTE EM RELAÇÃO AO ACOPLA- 
MENTO? 


O uso abusivo de objetos dublês para testar uma única classe indica que a 
classe sob teste possui problemas de acoplamento. É possível deduzir que 
uma classe que faz uso de muitos objetos dublês depende de muitas classes, 
e portanto, tende a ser uma classe instável. A esse padrão, dei o nome de 
Objetos Dublê em Excesso. 

A criação de objetos dublês que não são utilizados em alguns métodos de 
testes é outro feedback importante. Isso geralmente acontece quando a classe 
é altamente acoplada, e o resultado da ação de uma dependência não interfere 
na outra. Quando isso acontece, o programador acaba por escrever conjun- 
tos de testes, sendo que alguns deles lidam com um subconjunto dos obje- 
tos dublês, enquanto outros testes lidam com o outro subconjunto de objetos 
dublês. Isso indica um alto acoplamento da classe, que precisa ser refatorada. 
A esse padrão dei o nome de Objetos Dublê Não Utilizados. 

Quando o desenvolvedor começa o teste e percebe que a interface pública 
da classe não está amigável, pode indicar que abstração corrente não é clara o 
suficiente e poderia ser melhorada. A esse padrão, chamei de Interface Não 
Amigável. 

A falta de abstração geralmente também faz com que uma simples mu- 
dança precise ser feita em diferentes pontos do código. Quando uma mu- 
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dança acontece e o programador é obrigado a fazer a mesma alteração em 
diferentes testes, isso indica a falta de uma abstração correta para evitar a 
repetição desnecessária de código. A esse padrão dei o nome de Mesma Al- 
teração Em Diferentes Testes. Analogamente, o programador pode perceber 
a mesma coisa quando ele começa a criar testes repetidos para entidades difer- 
entes. Chamei esse padrão de Testes Repetidos Para Entidades Diferentes. 


8.10 CONCLUSÃO 


Neste capítulo, vimos padrões de feedback que os testes nos dão em relação 
ao acoplamento da classe. A grande maioria deles está totalmente relacionada 
ao mau uso de mock objects. 

Discutimos também que, para um melhor gerenciamento de dependên- 
cias, classes devem sempre tentar depender de módulos estáveis, diminuindo 
assim as chances da propagação de mudanças para a classe principal. Isso é 
alcançado através do bom uso de orientação a objetos e interfaces. 

A balança acoplamento e coesão é difícil de ser lidada. Classes coesas são 
fáceis de serem lidas e testadas, mas para que o sistema se comporte como o 
esperado, é necessário juntar todas essas pequenas classes. Esse momento é 
quando deixamos o lado do acoplamento se perder. Infelizmente, é impossível 
criar um sistema cujas classes são todas altamente coesas a pouco acopladas. 
Mas espero que ao final desses dois capítulos, eu tenha mostrado como atacar 
ambos os problemas e criar classes que balanceiam entre esses dois pontos- 
chave da orientação a objetos. 
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TDD e o encapsulamento 


Já discutimos sobre coesão e acoplamento nos capítulos anteriores, e vimos 
como os testes podem nos dar informações valiosas sobre esses dois pontos. 
Um próximo ponto importante em sistemas orientados a objetos é o encap- 
sulamento. 

Encapsular é esconder os detalhes de como a classe realiza sua tarefa; as 
outras classes devem conhecer apenas o que ela faz. Ao não encapsular cor- 
retamente regras de negócios em classes específicas, desenvolvedores acabam 
por criar código repetido, e espalhar as regras de negócio em diferentes partes 
do sistema. 

Neste capítulo, discutiremos como os testes podem nos ajudar a encontrar 
regras de negócio que não estão bem encapsuladas. 
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9.1 O PROBLEMA DO PROCESSADOR DE BOLETO 


É comum que uma fatura possa ser paga por meio de diferentes boletos. Para 
resolver esse problema, um processador de boletos passa por todos os boletos 
pagos para uma fatura e simplesmente faz o vínculo de ambos. 

Antes de começarmos, suponha a existência das classes Fatura, 
Boleto e Pagamento. Uma Fatura contém uma lista de Pagamento, 
que, por sua vez, armazena um valor e uma forma da pagamento (boleto, 
cartão de crédito etc.). Um Boleto contém apenas o valor pago do boleto. 


De antemão, já é possível imaginar alguns cenários para esse processador: 


e Usuário pagou com apenas um boleto; 


e Usuário utilizou mais de um boleto para pagar. 


Começando pelo primeiro cenário, mais simples, temos o teste a seguir, 
que cria um único boleto, invoca o processador, e ao final garante que o paga- 
mento foi criado na fatura: 


namespace CDC\Loja\FluxoDeCaixa; 


use CDC\Loja\Test\TestCase, 
CDC\Loja\FluxoDeCaixa\ProcessadorDeBoletos, 
CDC\Loja\FluxoDeCaixa\Fatura; 

use ArrayObject; 


class ProcessadorDeBoletosTest extends TestCase 


{ 


public function testDeveProcessarPagamentoViaBoletoUnico() 
{ 


$processador = new ProcessadorDeBoletos() ; 


$fatura = new Fatura(’Cliente’, 150.0); 
$boleto = new Boleto(150.0); 


$boletos = new ArrayObject(); 
$boletos->append ($boleto) ; 
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$processador->processa($boletos, $fatura) ; 


$this->assertEquals(1, count ($fatura->getPagamentos())); 
$this->assertEquals (150.0, 
$fatura->getPagamentos() [0]->getValor(), 
null, 0.00001); 


A implementação para fazer o teste passar é simples: 


namespace CDC\Loja\FluxoDeCaixa; 


use CDC\Loja\FluxoDeCaixa\Fatura, 
CDC\Loja\FluxoDeCaixa\Pagamento, 
CDC\Loja\FluxoDeCaixa\MeioPagamento; 
use ArrayObject; 


class ProcessadorDeBoletos 


{ 
public function processa(Array0bject $boletos, 
Fatura $fatura) 


$boleto = current ($boletos) ; 


$pagamento = new Pagamento($boleto->getValor(), 
MeioPagamento: : BOLETO) ; 

$pagamentosFatura = $fatura->getPagamentos() ; 

$pagamentosFatura->append ($pagamento) ; 


Agora, o próximo cenário é garantir que o processador de boletos con- 
segue processar um usuário que fez o pagamento por mais de um boleto: 


public function testDeveProcessarPagamentoViaMuitosBoletos() 
{ 


$processador = new ProcessadorDeBoletos(); 
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$fatura = new Fatura("Cliente", 300.0); 


$boleto1 = new Boleto(100.0); 
$boleto2 = new Boleto(200.0); 


$boletos = new ArrayObject(); 
$boletos->append ($boletol); 
$boletos->append ($boleto2) ; 


$processador->processa($boletos, $fatura) ; 
$this->assertEquals(2, count ($fatura->getPagamentos())); 


$valori = $fatura->getPagamentos() [0]->getValor(); 
$this->assertEquals(100.0, $valori, null, 0.00001); 


$valor2 = $fatura->getPagamentos() [1]->getValor(); 
$this->assertEquals(200.0, $valor2, null, 0.00001); 


Para fazer o teste passar, basta navegar pela lista de boletos e criar um 
pagamento para cada um deles: 


namespace CDC\Loja\FluxoDeCaixa; 


use CDC\Loja\FluxoDeCaixa\Fatura, 
CDC\Loja\FluxoDeCaixa\Pagamento, 
CDC\Loja\FluxoDeCaixa\MeioPagamento; 
use Array0Object; 


class ProcessadorDeBoletos 


{ 
public function processa(ArrayObject $boletos, 
Fatura $fatura) 


$pagamentosFatura = $fatura->getPagamentos() ; 


foreach($boletos as $boleto) { 
$pagamento = new Pagamento($boleto->getValor(), 
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MeioPagamento::BOLETO) ; 
$pagamentosFatura->append ($pagamento) ; 


Com o processador de boletos já funcionando, o próximo passo agora 
é marcar a fatura como paga, caso o valor dos boletos pagos seja igual ou 
superior ao valor da fatura. Ou seja, o sistema deve se comportar da seguinte 
maneira para os seguintes cenários: 


* Seo usuário pagar um único boleto com valor inferior ao da fatura, ela 
não deve ser marcada como paga; 


e Se o usuário pagar um único boleto com valor superior ao da fatura, 
ela deve ser marcada como paga; 


e Se o usuário pagar um único boleto com valor igual ao da fatura, ela 
deve ser marcada como paga; 


e Seo usuário pagar vários boletos e a soma deles for inferior ao da fatura, 
ela não deve ser marcada como paga; 


* Se o usuário pagar vários boletos e a soma deles for superior ao da 
fatura, ela deve ser marcada como paga; 


e Se o usuário pagar vários boletos e a soma deles for igual ao da fatura, 
ela deve ser marcada como paga. 


Apesar da quantidade de cenários ser grande, a implementação não é tão 
complicada assim. Precisamos guardar a soma de todos os boletos pagos e, 
ao final, verificar se ela é maior ou igual ao valor da fatura. Em caso positivo, 
basta marcar a fatura como paga. 


Novamente começando pelo cenário mais simples: 


public function 
testDeveMarcarFaturaComoPagoCasoBoletoUnicoPagueTudo() 
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$processador = new ProcessadorDeBoletos() ; 
$fatura = new Fatura(’Cliente’, 150.0); 


$boletos = new ArrayObject(); 
$boletos->append (new Boleto(150.0)); 


$processador->processa($boletos, $fatura) ; 


$this->assertTrue($fatura->isPago()); 


Fazendo o teste passar da maneira que discutimos anteriormente: 


public function processa(Array0bject $boletos, Fatura $fatura) 


{ 
$valorTotal = 0; 


$pagamentosFatura = $fatura->getPagamentos() ; 
foreach($boletos as $boleto) { 
$pagamento = new Pagamento($boleto->getValor(), 
MeioPagamento: :BOLETO) ; 
$pagamentosFatura->append ($pagamento) ; 


$valorTotal += $boleto->getValor (); 


if( $valorTotal >= $fatura->getValor() ) 1 
$fatura->setPago (true) ; 


Com todos os testes verdes, é hora de discutirmos sobre a implementação 
feita até então. 
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DEVO ESCREVER OS OUTROS TESTES? 


Mesmo que a implementação pareça já resolver todos os cenários pro- 
postos, é importante que esses testes sejam automatizados. 

Lembre-se que amanhã a implementação poderá mudar. Como 
garantir que a nova implementação funcionará para todos os casos em 
que a implementação atual funciona? Todo código que você acabou de 
escrever parece simples e funcional, mas não se esqueça que ele ficará lá 
para sempre e será mantido por muitas outras pessoas. 

Portanto, não se deixe enganar. Escreva os testes e garanta que nen- 
huma futura evolução quebrará o que já funciona hoje. 











9.2 OUVINDO O FEEDBACK DOS TESTES 


Apesar de essa classe atender a regra de negócio, o código produzido não 
é dos melhores. O que aconteceria com o sistema caso precisássemos criar 
agora um processador de cartão de crédito? Seria necessário repetir a mesma 
lógica de marcar uma fatura como paga lá. Ou seja, a cada nova forma de 
pagamento, trechos de código seriam replicados entre classes. E não há ne- 
cessidade para se discutir os problemas de código repetido. 

O princípio ferido aqui é justamente o encapsulamento. As classes de- 
vem ser responsáveis por manter o seu próprio estado; são elas que devem 
conhecer as suas próprias regras de negócio. Quando a regra não é seguida, 
pedaços da regra de negócio são espalhadas pelo código. É exatamente isso o 
que aconteceu no exemplo: a regra de marcar uma fatura como paga está fora 
da classe Fatura. 

O teste, por sua vez, nos dá dicas sobre esse problema. Veja por exem- 
plo qualquer um dos testes escritos na classe ProcessadorDeBoletoTest. 
Todos eles fazem asserções na classe Fatura. A pergunta é: por que os testes 
de uma classe fazem asserções somente em outras classes? 

Responder essa pergunta pode ser difícil. Essa valiosa dica pode estar nos 
avisando sobre possíveis problemas de encapsulamento na classe que recebe 
a asserção. Neste caso, a classe Fatura não está encapsulando bem as suas 
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regras de negocio. 


9.3 TELL, DON’T ASK E LEI DE DEMETER 


Classes como a ProcessadorDeBoletos, que “conhecem demais” sobre o 
comportamento de outras classes não são bem vistas em sistemas orientados 
a objetos. É comum ouvir o termo intimidade inapropriada, já que a classe 
conhece detalhes que não deveria de alguma outra classe. 

Repare a implementação do método processa () em relação ao pro- 
cesso de marcar a fatura como paga. Veja que ele faz uma pergunta para a 
fatura (pergunta o valor dela), e depois, com a resposta em mãos, toma uma 
ação (marca ou não a fatura como paga). Em códigos orientados a objetos, 
geralmente dizemos que as classes não devem fazer perguntas e tomar de- 
cisões baseadas nas respostas, mas sim mandar o objeto executar uma ação, 
e ele por conta própria tomar a decisão certa. Essa ideia é conhecida por Tell, 
Don't Ask. 

Em nosso exemplo, a ideia seria mandar a classe Fatura se marcar como 
paga, caso necessário, afinal ela deve ser a responsável por manter seu próprio 
estado. Essa ação poderia ser tomada, por exemplo, no momento em que 
adicionamos um novo pagamento. 

Sea Fatura tivesse um método adicionaPagamento (Pagamento 
Sp), que, além de adicionar o pagamento na fatura, ainda somasse os val- 
ores pagos e marcasse a fatura como paga se necessário, o problema estaria 
resolvido. Não teríamos mais 0 foreach do lado de fora da classe. Essa regra 
estaria dentro da classe, encapsulada. 

Uma outra possível maneira de descobrir por possíveis problemas de en- 
capsulamento é contando a quantidade de métodos invocados em uma só 
linha dentro de um único objeto. Por exemplo, imagine o seguinte código: 


$a->getB() ->getC() ->getD() ->fazAlgumaCoisa() ; 


Para invocar o comportamento desejado, partimos de “a”, pegamos “b”, 
“c” e “d”. Relembre agora a discussão sobre acoplamento. Quando uma classe 
depende da outra, mudanças em uma classe podem se propagar para a classe 
principal. Perceba agora que a classe que contém não está acoplada somente à 
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«o» > CC 99 


classe do tipo do atributo “a”, mas indiretamente também aos tipos de “b”, “c” e 
“d”. Qualquer mudança na estrutura deles pode impactar na classe principal. 
Isso pode ser considerado também um problema de encapsulamento. A 


«o» 


classe do tipo “a” está expondo demais sua estrutura interna. O “mundo de 

fora” sabe que ela lá dentro tem “b”, que por sua vez, tem “c’, “d”, e assim 

por diante. Se o comportamento fazAlgumaCoisa () deve realmente ser 
co) 


invocado, pode-se fazer algo como um método dentro de “a” que esconde o 
processo de invocá-lo: 


$a->fazAlgumaCoisa() ; 


class A 


{ 


public function fazAlgumaCoisa() { 
$this->getB() ->getC() ->fazAlgumaCoisa() ; 


Diminuir a quantidade de iterações com os objetos, ou seja, navegar 
menos dentro deles, é o que conhecemos por Lei de Demeter. Ela nos diz jus- 
tamente isso: tente nunca conversar com classes que estão dentro de classes; 
para isso, crie um método que esconda esse trabalho pra você. Dessa forma, 
você encapsula melhor o comportamento esperado e ainda reduz o acopla- 
mento. 
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ANICHE DIZ: DEVO SEGUIR A LEI DE DEMETER À RISCA? 


Como tudo em engenharia de software, não. A Lei de Demeter, apesar 
de muito interessante, às vezes pode mais atrapalhar do que ajudar. 

Geralmente não ligo para linhas como 
Spessoa->getEndereco () ->getRua (), pois estamos apenas 
pegando dados de um objeto. Não faz sentido criar um método 








Spessoa->getRua (), ou Spessoa->getX() para todo dado que 
representa uma pessoa. É simplesmente trabalhoso demais. 

Essa é geralmente a minha regra: para exibição, aceito não seguir a re- 
gra. Mas para invocar um comportamento, geralmente penso duas vezes 
antes de não seguir. 











9.4 RESOLVENDO O PROBLEMA DO PROCESSADOR DE 
BOLETOS 


Conforme já discutido, é necessário levar a regra de negócios da marcação da 
fatura como paga para dentro da própria classe Fatura. Seguindo a ideia do 
método adicionaPagamento (), vamos fazê-lo adicionar o pagamento e 


marcar a fatura como paga caso necessário: 


namespace Loja\FluxoDeCaixa; 


use ArrayObject; 
use Loja\FluxoDeCaixa\Pagamento; 


class Fatura 


{ 
Li es 
public function adicionaPagamento(Pagamento $pagamento) 


{ 
$this->pagamentos->append ($pagamento) ; 
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$valorTotal = 0; 


foreach( $this->pagamentos as $p ) { 
$valorTotal += $p->getValor(); 


if( $valorTotal >= $this->valor ) 1 
$this->pago = true; 


O processador de boletos volta a ficar com o código enxuto: 


public function processa(Array0bject $boletos, Fatura $fatura) 


{ 
foreach($boletos as $boleto) { 
$pagamento = new Pagamento($boleto->getValor(), 
MeioPagamento: : BOLETO) ; 


$fatura->adicionaPagamento ($pagamento) ; 


Veja que agora ele não conhece detalhes da classe Fatura. Isso é re- 
sponsabilidade da própria fatura. Não há mais intimidade inapropriada. O 
desenvolvedor deve mover os testes que garantem a marcação de uma fatura 
como paga para dentro da classe FaturaTest, já que isso não é mais um 
comportamento do processador de boletos. 


9.5 O QUE OLHAR NO TESTE EM RELAÇÃO AO ENCAP- 
SULAMENTO? 


Testes que lidam demais com outros objetos ao invés de lidar com o objeto 
sob teste podem estar avisando o desenvolvedor em relação a problemas de 
encapsulamento. A própria não utilização da Lei de Demeter, tanto nos testes 
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quanto no código de produção, também pode avisar sobre os mesmos prob- 
lemas. 

Isso é comum em bateria de testes de classes anêmicas [5]. Um modelo 
anêmico é aquele em que classes contêm apenas atributos ou apenas métodos. 
Classes que contêm atributos apenas representam as entidades, enquanto out- 
ras classes, que contêm apenas métodos, realizam ações sobre eles. Esse tipo 
de projeto (que faz com que o código se pareça mais com um código procedu- 
ral do que com um código orientado a objetos) deve ser evitado ao máximo. 


9.6 CONCLUSÃO 


Neste capítulo, discutimos o ponto que faltava para encerrarmos a discussão 
sobre feedback dos testes em relação a pontos importantes em projetos orien- 
tados a objetos: coesão, acoplamento e encapsulamento. 

Muito provavelmente você, desenvolvedor, encontrará outros padrões de 
feedback que o teste pode dar. Siga seu instinto, experiência e conhecimento. 
O importante é ter código de qualidade ao final. 
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Testes de integração e TDD 


Até o momento, escrevemos apenas testes de unidade. Será que faz sentido 
escrever testes ou até mesmo praticar TDD para outros níveis de teste? 

Neste capítulo, discutiremos sobre o mau uso de mocks, testes para acesso 
a dados, testes de integração, e quando não os fazer. 


10.1 TESTES DE UNIDADE, INTEGRAÇÃO E SISTEMA 


Podemos escrever um teste de diferentes maneiras, de acordo com o que es- 
peramos obter dele. Todos os testes que escrevemos até agora são conhecidos 
por testes de unidade. 

Um teste de unidade é aquele que garante que uma classe funciona, de 
maneira isolada ao resto do sistema. Ou seja, testamos o comportamento 
dela sem nos preocuparmos com o comportamento das outras classes. Uma 
vantagem dos testes de unidade é que eles são fáceis de serem escritos e rodam 
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muito rápido. A desvantagem deles é que eles não simulam bem a aplicação 
no mundo real. No mundo real, temos as mais diversas classes trabalhando 
juntas para produzir o comportamento maior esperado. 

Se quisermos um teste que se pareça com o mundo real, ou seja, que real- 
mente teste a aplicação do ponto de vista do usuário, é necessário escrever o 
que chamamos de teste de sistema. Um teste de sistema é aquele que é idên- 
tico ao executado pelo usuário da aplicação. Se sua aplicação é uma aplicação 
web, esse teste deve subir o browser, clicar em links, submeter formulários etc. 
A vantagem desse tipo de teste é que ele consegue encontrar problemas que 
só ocorrem no mundo real, como problemas de integração entre a aplicação 
e banco de dados, entre outros. O problema é que eles geralmente são mais 
difíceis de serem escritos e levam muito mais tempo para serem executados. 

No entanto, muitas vezes queremos testar não só uma classe, mas tam- 
bém não o sistema todo; queremos testar a integração entre uma classe e um 
sistema externo. Por exemplo, classes DAO (responsáveis por fazer toda a co- 
municação com o banco de dados) devem ser testadas para garantir que as 
consultas SQL estão escritas corretamente, mas de maneira isolada às outras 
classes do sistema. Esse tipo de teste, que garante a integração entre 2 pontos 
da aplicação, é conhecido por teste de integração. 

O desenvolvedor deve fazer uso dos diferentes níveis de teste para garantir 
qualidade do seu sistema. Mas deve sempre ter em mente que, quanto mais 
parecido com o mundo real, mais difícil e caro o teste será. 
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Mais parecido Mais dificil 
com o e caro de 
mundo reai ser escrito 


10.2 QUANDO NÃO USAR MOCKS? 


O primeiro passo para que um teste deixe de ser exclusivamente de unidade 
e passe a ser de integração é não usar mocks e passar dependências concretas 
para a classe sob teste. 

Muitos desenvolvedores, inclusive, defendem que um bom teste nunca 
faz uso de mocks. O argumento deles é de que mocks acabam por “esconder” 
possíveis problemas que só seriam pegos na integração. É o argumento de 
sempre em relação a testes de unidade e testes de integração. O ponto não é 
descobrir se devemos ou não usar mocks, mas sim quando ou não usá-los. 

Veja, por exemplo, um dos testes implementados para a calculadora de 
salário: 


public function 
testCalculoSalarioDesenvolvedoresComSalarioAbaixoDoLimite() 


$calculadora = new CalculadoraDeSalario(); 


$desenvolvedor = new Funcionario( 
"Andre", 1500.0, "desenvolvedor") ; 
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$salario = $calculadora->calculaSalario($desenvolvedor) ; 


$this->assertEquals(1500.0 * 0.9, $salario, null, 0.00001); 


Esse teste garante o comportamento da classe 
CalculadoraDeSalario. Idealmente, gostaríamos de testá-la inde- 
pendente do comportamento das outras classes. Mas veja que no teste 
instanciamos um Funcionario. Usamos a classe concreta e não fizemos 
uso de mock. Por quê? 

Geralmente, classes que representam entidades, serviços, utilitários, ou 
qualquer outra coisa que encosta em infraestrutura, não são mockadas. Elas 
são classes puras e simples e mocká-las só irá dar mais trabalho ao desen- 
volvedor. 

Ao tomar essa decisão, diminuímos a qualidade do retorno desse teste, 
afinal ele pode falhar não por culpa da calculadora de salário, mas sim por 
culpa do funcionário. Apesar de não ser o melhor dos mundos, é uma troca 
justa entre produtividade e feedback. 

Opte por mockar classes que lidam com infraestrutura e que tornariam 
seu teste muito complicado. Por exemplo, relembre nosso gerador de nota 
fiscal. A nota era persistida em um banco de dados e depois enviada para o 
SAP. Preparar tanto o banco quanto o SAP para receber o teste não é fácil. 
Portanto, simular a interação de ambas as classes é uma boa ideia. 

Use mocks também quando sua classe lida com interfaces. Em 
nossa versão final do gerador de nota fiscal, criamos a interface 
AcaoAposGerarNota. Nesses casos, o mais simples talvez seja mockar a 
interface em vez de criar uma implementação concreta “simples”, somente 
para o teste. 

Por outro lado, um ponto negativo do uso de mock objects é o alto acopla- 
mento criado entre o código de teste e o código de produção. Já discutimos o 
conceito de encapsulamento no capítulo anterior: uma classe deve esconder 
a maneira como ela implementa determinada regra de negócio. Quando um 
teste faz uso de um mock, esse teste passa a ter uma “intimidade inapropri- 
ada” com a implementação; ele passa a saber quais métodos serão invocados, 
e como a classe deve reagir de acordo com o resultado. 
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Veja o código de produção e teste a seguir, responsável por calcular o im- 
posto de um pedido, de acordo com uma tabela de preços: 


namespace Loja\Tributos; 

use Loja\Test\TestCase, 
Loja\FluxoDeCaixa\Pedido, 
Loja\Tributos\CalculadoraDeImposto; 


use Mockery; 


class CalculadoraDeImpostoTest extends TestCase 


{ 


public function 
testCalculoImpostoParaPedidosSuperiorA2000Reais () 


$tabela = Mockery: :mock("Loja\Tributos\Tabela") ; 
// ensinando o mock a devolver 0.1 caso o método 
// paraValor seja invocado com o valor 2500.0 
$tabela->shouldReceive("paraValor") 


->with(2500.0)->andReturn(0.1); 


$pedido = new Pedido("Andre", 2500.0, 3); 
$calculadora = new CalculadoraDeImposto($tabela) ; 


$valor = $calculadora->calculaImposto ($pedido) ; 


$this->assertEquals( (2500.0 * 0.1) , 
$valor, null, 0.00001); 


namespace Loja\Tributos; 


use Loja\FluxoDeCaixa\Pedido; 
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use Loja\Tributos\Tabela; 


class CalculadoraDeImposto 


{ 
protected $tabela; 
public function __construct(Tabela $tabela) 
{ 
$this->tabela = $tabela; 
} 
public function calculaImposto (Pedido $pedido) 
{ 
$taxa = $this->tabela->paraValor( 
$pedido->getValorTotal()); 
return $pedido->getValorTotal() * $taxa; 
} 
} 


Veja que o teste calculoImpostoParaPedidosSuperiorA2000Reais 
sabe exatamente qual método será invocado no código de produção. Isso 
quer dizer que qualquer mudança na implementação do método pode fazer 
o teste quebrar. Ou seja, quanto maior o uso de mocks, mais delicado e frágil 
seu teste fica. 

Muitos desenvolvedores, quando são apresentados à ideia de mock ob- 
jects, passam a mockar todos os objetos nos seus testes. Muitos testes escritos 
com esse pensamento passam a ser inúteis, pois acabam “testando o mock”. 
No capítulo seguinte, veremos um exemplo disso. Mas um primeiro ponto de 
alerta é: se sua bateria de testes só faz asserções em objetos dublês, talvez essa 
bateria não lhe esteja dando o feedback necessário. 

Portanto, faça uso de mock objects quando utilizar a instância concreta 
da classe for complexo ou trabalhoso. Quando usar a classe concreta não for 
diminuir o feedback dos seus testes e nem dificultar a escrita dele, então use a 
classe concreta. 
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10.3 TESTES EM DAOs 


Testar classes que fazem uso de DAOs é simples; basta fazermos uso de mocks. 
Mas o DAO é uma classe, e que também merece ser testada. Testar um DAO é 
fundamental. É muito comum errarmos em consultas SQL, esquecermos de 
algum campo no momento da inserção ou atualizar campos que não deveriam 
ser atualizados. 

Mas, como toda classe que lida com infraestrutura, testá-la é um pouco 
mais complicado. É razoavelmente óbvio que para se testar um DAO é 
necessário comunicar-se de verdade com um banco de dados real. Nada de 
simulações ou mocks, afinal essa é a única maneira de garantir que a consulta 
foi escrita e executada com sucesso pelo banco de dados. 

Imagine um DAO qualquer, por exemplo, o seguinte, que contém um 
método que salva o produto, outro que busca um produto pelo seu id, e 
outro que devolve somente os produtos ativos. Veja que esse DAO faz uso da 
classe PDO previamente instanciada e configurada corretamente fornecendo 
uma conexão com um banco de dados existente: 


namespace Loja\Persistencia; 


use PDO; 
use Loja\Produto\Produto; 


class ProdutoDao 


{ 


private $conexao; 


public function __construct(PDO $conexao) 


{ 


$this->conexao = $conexao; 


public function adiciona(Produto $produto) 
{ 

$sqlString = "INSERT INTO “produto” "; 

$sqlString .= "(descricao,valor_unitario,status) "; 
"VALUES (?, ?, ?)"; 


$sqlString 
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$stmt = $this->conexao->prepare ($sqlString) ; 
$stmt->bindParam(1, $produto->getDescricao()) ; 
$stmt->bindParam(2, $produto->getValorUnitario()); 
$stmt->bindParam(3, $produto->getStatus()); 


$stmt->execute() ; 


return $this->conexao; 


} 

public function porId($id) 

{ 
$sqlString = "SELECT * FROM “produto” WHERE id=". $id; 
$consulta = $this->conexao->query ($sqlString) ; 
return $consulta->fetch(PDO: :FETCH_ASSOC) ; 

} 


public function ativos() 


{ 
$sqlString = "SELECT * FROM `produto` WHERE status=1"; 
$consulta = $this->conexao->query ($sqlString) ; 
return $consulta->fetchAll (PDO: :FETCH_ASSOC) ; 

} 


Precisamos testar cada um desses métodos. Vamos comecar pelo 
adiciona (). Como todo teste, ele conterá as mesmas 3 partes: cenário, ação 
e validação. O cenário e ação são similares aos dos nossos testes anteriores. 
Basta criarmos um produto e invocar o método adiciona: 


namespace Loja\Persistencia; 


use Loja\Test\TestCase, 
Loja\Persistencia\ConexaoComBancoDeDados, 
Loja\Persistencia\ProdutoDao, 
Loja\Produto\Produto; 
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class ProdutoDaoTest extends TestCase 


{ 
public function testDeveAdicionarUmProduto() 
{ 
$conn = (new ConexaoComBancoDeDados() )->getConexao() ; 
$produtoDao = new ProdutoDao($conn) ; 
$produto = new Produto("Geladeira", 150.0); 
$produtoDao->adiciona($produto) ; 
// como validar? 
} 
} 


O problema é justamente como validar que o dado foi inserido com 
sucesso. Precisamos garantir que o elemento foi salvo no banco de dados. 
A única maneira é justamente fazendo uma consulta de seleção no banco de 
dados e verificando o produto lá. Para isso, podemos usar o próprio método 
porId() do DAO, e verificar se o objeto salvo é igual ao produto criado: 


public function testDeveAdicionarUmProduto() 


{ 
$conexao = (new ConexaoComBancoDeDados() )->getConexao() ; 
$produtoDao = new ProdutoDao($conexao) ; 


$produto = new Produto("Geladeira", 150.0); 
// Sobrescrevendo a conexão para continuar trabalhando 
// sobre a mesma já instanciada 


$conexao = $produtoDao->adiciona($produto) ; 


// buscando pelo id para 
// ver se esta igual o produto do cenario 


$salvo = $produtoDao->porId($conexao->lastInsertId()); 
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$this->assertEquals($salvo["descricao"], 
$produto->getDescricao()); 
$this->assertEquals($salvo["valor_unitario"], 
$produto->getValorUnitario()) ; 
$this->assertEquals($salvo["status"], $produto->getStatus()); 


Ainda temos um problema. Nosso ProdutoDao faz uso de uma conexão 
com o banco de dados. Todo DAO tem sua forma de conectar com o banco 
de dados. É necessário passar uma conexão concreta, que bata em um banco 
de dados de teste, para que o teste consiga executar. 





MOCKANDO A CONNECTION/SESSION? 


Já ouvi falar de desenvolvedores que testam DAOs mockando a Con- 
nection, Session (do Hibernate no Java), Doctrine ou Propel (no PHP), ou 
qualquer que seja a sua forma de acesso ao banco de dados. 

Minha pergunta é: em uma classe cuja única responsabilidade é in- 
teragir com o sistema externo, qual a vantagem de isolá-la desse sistema? 
Não faz sentido. Classes que lidam com infraestrutura devem ser testadas 
com a infraestrutura real que lidarão. É trabalhoso, mas necessário. 











Não há uma maneira ideal para fazer isso. Crie a conexão da maneira que 
achar necessário, apontando para um banco de dados de teste. Geralmente 
isso é feito em um método de inicialização do próprio teste: 


private $conexao; 
protected function setUp() 
{ 

parent::setUp() ; 


$this->conexao = new PDO("sqlite:/tmp/test.db") ; 


$this->conexao->setAttribute( 
PDO::ATTR_ERRMODE, PDO::ERRMODE EXCEPTION); 
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$this->criaTabela(); 


protected function criaTabela() 


{ 
$sqlString = "CREATE TABLE produto "; 
$sqlString .= "(id INTEGER PRIMARY KEY, descricao TEXT, "; 
$sqlString .= "valor_unitario TEXT, status TINYINT(1) );"; 
$this->conexao->query ($sqlString) ; 

} 


Outro problema é limpar esse banco de dados. Imagine por exemplo um 
teste que conte a quantidade de produtos cadastrados. Se já tivermos algum 
produto cadastrado antes da execução do teste, provavelmente o teste falhará, 
pois ele não contava com esse dado a mais. Portanto, cada teste precisa ter o 
banco de dados limpo para que dados antigos não influenciem no resultado. 

É comum fazermos uso de métodos de finalização para isso. No método 
tearDown, removemos o banco previamente criado, afinal de contas para 
este teste utilizamos o banco Sqlite, que nada mais é que um arquivo na pasta 
temporária do seu Sistema Operacional. Veja um exemplo: 


protected function tearDown() 
{ 


parent: :tearDown() ; 
unlink("/tmp/test.db") ; 


Novamente, testes de integração podem se tornar complicados. Por ex- 
emplo, caso um teste exija dados pré-salvos no banco de dados, é responsabil- 
idade do teste de montar todo o cenário e persisti-lo. 
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ANICHE DIZ: ROLLBACK OU TRUNCAR TABELAS? 


Dar um rollback nas tabelas é geralmente a solução mais simples, pois 
basta uma linha de código. 

Mas já vi testes passarem e em produção a funcionalidade não fun- 
cionar, justamente porque o banco recusava as inserções no momento do 
“commit da transação”. Portanto, uma solução mais completa seria comi- 
tar a transação, e em seguida, truncar todas as tabelas. Naturalmente é 
uma solução que dá mais trabalho. 








ANDRE DIZ: DELETAR O BANCO APÓS O TESTE 


Complementando o que o Aniche disse, com o PHP é muito comum 
realizarmos testes utilizando o banco de dados Sqlite por ser leve, o que 
torna os testes mais rápidos de serem executados. O banco Sqlite é um 
simples arquivo em um local de seu Sistema Operacional, que deixa ainda 
mais fácil sua manutenção pois não precisamos de parâmetros de auten- 
ticação para acessá-lo. Desta forma, é muito comum no método con- 
strutor do teste ( set Up) realizarmos a criação do banco e, em seguida, a 
estrutura da tabela em que a classe de testes corrente realizará as queries. 
Como este processo todo é muito rápido, o mais indicado neste cenário é 
simplesmente deletar o banco de dados antes do próximo teste. Fazemos 
isso no método destrutor do teste ( tearDown). Desta forma, garanti- 
mos que em cada teste realizado não haverá o mínimo vestígio de um 
teste anterior que possa fragilizar a integridade e consequentemente no 
seu resultado. 











Testar o método ativos () também não é difícil. Precisamos montar 
um cenário onde o banco de dados contenha produtos ativos e não ativos. 
O retorno do método deve conter apenas os não ativos. Repare ali que, após 
instanciarmos os objetos, os salvamos explicitamente no banco de dados: 


public function testDeveFiltrarAtivos() 


{ 
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$produtoDao = new ProdutoDao ($this->conexao) ; 


$ativo = new Produto("Geladeira", 150.0); 
$inativo = new Produto("Geladeira", 180.0); 
$inativo->inativa(); 


$produtoDao->adiciona($ativo) ; 
$produtoDao->adiciona($inativo) ; 


$produtosAtivos = $produtoDao->ativos() ; 


$this->assertEquals(1, count ($produtosAtivos) ) ; 
$this->assertEquals(150.0, 
$produtosAtivos[0] ["valor_unitario"]); 


Portanto, lembre-se de testar seus DAOs batendo em um banco de dados 
real. Não use mocks. Garanta realmente que suas consultas SQLs funcionam 
da maneira como você espera. Use também sua criatividade para escrever o 
teste; basta ter em mente que é um teste como qualquer outro. Você precisa 
montar um cenário (usando as várias práticas já discutidas aqui, como Test 
Data Builders etc.), invocar um método no seu DAO, e encontrar uma maneira 
de garantir que seu banco respondeu corretamente. 


10.4 DEVO USAR TDD EM TESTES DE INTEGRAÇÃO? 


Repare que na seção anterior não usamos TDD. Tínhamos o DAO já escrito 
e depois o testamos. Em classes que lidam com infraestrutura, esse é geral- 
mente o comportamento padrão. TDD faz muito sentido quando queremos 
testar algoritmos ou projetos de classe complexos. Classes como DAOs geral- 
mente não apresentam uma lógica complicada, mas sim apenas código que 
integra com outros sistema. No caso do DAO, seus métodos são geralmente 
compostos por uma SQL e uma invocação de método. 

Como também discutido no capítulo sobre acoplamento, ao praticar 
TDD, o desenvolvedor acaba por criar interfaces que representam a interação 
com sistemas externos. Essas interfaces tendem a ser bem claras e especifi- 
cas. Ao terminar a implementação da classe principal, o desenvolvedor parte 
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para as classes ao redor, como DAOs etc. Nessa hora, como não há muitas de- 
cisões a serem tomadas, não há grandes problemas em implementar a classe 
e só depois escrever o teste. 

É óbvio que, caso você esteja criando alguma integração mais complexa, 
TDD muito provavelmente o ajudará a entender melhor o problema e o guiará 
(através do já conhecido feedback) a uma solução melhor. Analise caso a caso. 


10.5 TESTES EM APLICAÇÕES WEB 


Novamente, a ideia de se escrever testes antes pode ser aplicada a qualquer 
contexto. Se o programador sentir que isso irá ajudar, então deve fazê-lo. Em 
sistemas web, geralmente a grande dificuldade de se escrever um teste é jus- 
tamente separar as “camadas de integração” da camada de domínio. 

Independente do framework escolhido para ajudar no desenvolvimento 
(Zend Framework, Symfony, CakePHP, Laravel, etc.), o desenvolvedor é obri- 
gado a escrever uma camada que “conecta” o mundo web, cheio de requi- 
sições, respostas, HTTP e HTML, com o mundo de domínio, cheio de classes 
de negócio ricas. Chamamos essa camada geralmente de “controlador” (ou 
Controller). Controllers devem ser adaptadores. Não devem possuir regras 
de negócio, apenas regras de fluxo e exibição. 

Veja um exemplo de um método de um controlador de uma aplicação es- 
crita com CakePHP, responsável por decidir qual o próximo passo do usuário 
em um sistema de ensino online. Se o aluno já terminou o curso, o contro- 
lador redireciona para o certificado, se ele não terminou, redireciona para a 
próxima seção que ele deve fazer etc.: 


public function continueCourse($courseId = null) { 


if( !$this->Course->exists($courseld) ) { 
throw new NotFoundException("Curso não localizado"); 


$course = $this->Course->read($courseld) ; 
$enrollment = $this->Enrollment 
->getEnrollmentFor ( 
$this->Auth->user("id"), $course) ; 
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if( $enrollment->hasAchievedCertification() ) { 


$this->redirect (array ( 
"controller" => "users", 
"action" => "certificate", 
"courseld" => $courseld)); 


} else if( $course->isPreSale() ) { 


$this->redirect (array ( 
"controller" => "home", 
"action" => "dashboard")); 


} else { 
$section = $this->Enrollment 
->getEnrollmentFor ( 
$this->Auth->user ("id"), $course) 
->continuing() ;s 


$this->redirect (array ( 
"controller" => "sections", 
"action" => "show", 
"courseld" => $courseld, 
"sectionId" => $section->getNumber ())); 


Veja que nao há regras de negócio nesse código. As regras de negócio es- 
tão isoladas em classes de domínio (e, como mostrado ao longo do livro, são 
facilmente testadas) e o acesso à infraestrutura, como banco de dados, tam- 
bém está isolado (e pode ser testado também, como discutido nesse capítulo). 
Ao isolar todo código de negócio da camada de controle, o desenvolvedor 
consegue testar a “parte que importa”. 

Agora, um ponto interessante a ser discutido é sobre a necessidade de 
se testar um controlador ou não. Muitos desenvolvedores gostam de testar 
controladores a fim de garantir que eles sempre tomarão a decisão certa sobre 
a próxima página a ser exibida. 
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Mas veja o código anterior. Para testá-lo, são necessários muitos mocks: 
courses é uma Model que busca cursos, enrollments é uma Model que busca 
por inscrições em cursos, result é responsável por redirecionar para outro 
controller e/ou action. Um simples teste fará uso de diversos mocks. Já dis- 
cutimos isso anteriormente: isso mostra o alto acoplamento dessa classe. 

Controladores são um bom exemplo de classes cujo acoplamento alto é 
aceitável. De novo, eles são adaptadores, portanto, se conectam a dois mun- 
dos diferentes, cada um com sua classe. Já discutimos também sobre como 
testes que usam mocks são altamente acoplados com a implementação. Eles 
sabem como a implementação funciona e qualquer mudança na implemen- 
tação impacta no teste. São testes frágeis. 

Geralmente, eu opto por não escrever testes de unidade para contro- 
ladores. Acho esses testes muito frágeis, mudam o tempo inteiro e não dão o 
feedback esperado. Bugs em controladores geralmente acontecem não pelo 
seu código em si, mas por problemas de integração com a camada web. 
Nomes de elementos no HTML que são submetidos pelo formulário e cap- 
turados pelo controlador são causadores de muitos bugs. 

Sim, essa integração deve ser testada. Mas, em minha opinião, a mel- 
hor solução é escrever um teste de sistema. Ou seja, deve-se subir o browser, 
navegar na aplicação web, submeter formulários e validar a saída. Para testes 
como esses, ferramentas como Selenium (que sabem como abrir o browser e 
manipular os elementos) são de grande valia. 

Fazer TDD em testes de sistema tem sido estudado pela comunidade 
acadêmica há algum tempo. Eles batizaram a técnica de ATDD (Acceptance 
Test-Driven Development). A ideia é escrever um teste de sistema que falha, 
em seguida fazer o ciclo de TDD para criar todas as classes necessárias para 
implementar a funcionalidade, e por consequência, fazer o teste de sistema 
passar. Na prática, não vejo como fazer isso funcionar de maneira produtiva. 
Um teste de sistema é um teste caro e frágil de ser escrito. Gosto deles, mas 
escritos após a implementação. 
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10.6 CONCLUSÃO 


Não há uma receita mágica para escrever testes de integração. Mas lembre-se 
que, caso você tenha uma classe cuja responsabilidade é justamente se integrar 
com outro sistema, você deve fazer um teste de integração. 

Consiga uma réplica do sistema ou alguma maneira de consumi-lo para 
testes, seja ele um banco de dados, um serviço web, ou qualquer outra coisa. 

O grande desafio, no fim, é conseguir montar o cenário e validar a saída 
nesse serviço externo. Talvez você escreva um “teste feio”, com muitas lin- 
has de código. Mas não se preocupe, seu sistema estará bem testado e você 


dormirá em paz. 
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Quando nao usar TDD? 


Ao longo deste livro, discutimos as diversas vantagens da escrita de testes de 
unidade e TDD, tanto na qualidade externa quanto na qualidade interna do 
sistema. 

Mas sera que devemos fazer uso da pratica 100% do tempo? Neste capitulo 
discutiremos quando usar e, mais importante, quando nao usar TDD. 


11.1 QUANDO NAO PRATICAR TDD? 


Repetindo uma frase que apareceu diversas vezes ao longo do livro: em engen- 
haria de software, nao se deve usar as palavras “nunca” e “sempre”. Nenhuma 
pratica deve ser usada 100% do tempo ou descartada de uma vez. 

Em momentos em que o desenvolvedor nao sabe bem como resolver 
o problema, dada sua complexidade, ou nao sabe bem como projetar uma 
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classe, dada sua necessidade de ser flexível, TDD pode ser de grande valia 
devido ao seu constante feedback sobre a qualidade do código. 

Mas, em momentos nos quais o desenvolvedor já sabe como resolver o 
problema, tanto do ponto de implementação, quanto do ponto de vista de de- 
sign, não utilizar TDD pode não ser um problema tão grande assim. Uma 
outra situação em que o uso de TDD pode ser desnecessário é durante a es- 
crita de códigos que lidam com infraestrutura ou com camada de visualização. 
Durante a implementação de um DAO, por exemplo, não há grande necessi- 
dade de feedback em relação à qualidade do código (pois é geralmente uma 
SQL) e do projeto de classes (geralmente DAOs são classes cujas decisões de 
design são simples). 

Novamente, a ideia não é usar TDD porque a prática está em alta no mer- 
cado, mas sim pelo benefício que ele agrega ao processo. Se não há a ne- 
cessidade de feedback constante naquele momento, não há necessidade de se 
praticar TDD. O que talvez seja difícil é justamente julgar corretamente quais 
são esses momentos. A experiência do desenvolvedor, em desenvolvimento 
de software e em TDD, é crucial. 

Outro ponto importante a ser levantado é que estamos discutindo a não 
utilização de TDD em alguns momentos, mas não a falta de testes. Caso o 
desenvolvedor opte por não usar TDD, espera-se que ele, após a implemen- 
tação, escreva testes para aquela funcionalidade, sejam eles de unidade ou 
integração. É preciso garantir a qualidade externa de maneira sustentável, e 
como discutido na introdução, essa maneira é automatizando o teste. 

Deixe sua experiência guiá-lo também na escolha de usar ou não TDD. 
Lembre-se que no fim das contas, o que precisamos é de feedback sobre o que 


estamos fazendo. 


174 


Casa do Código Capítulo 11. Quando não usar TDD? 








VOCE NÃO FAZ TDD 100% DO TEMPO ENTÃO? 


Aniche diz: Não. Dou preferência sim para TDD, mas nos casos dis- 
cutidos aqui, geralmente opto por não fazer. Mas, mesmo quando não 
faço, tento ao máximo aumentar a quantidade de feedback que recebo 
dos testes que escrevo após a implementação. 

Ou seja, mesmo não praticando TDD, tento sempre escrever uma pe- 
quena quantidade de código e em seguida um teste. E repito. 

Andre diz: Não. Como sabemos, o mundo do PHP é muito dinâmico, 
podemos estar desenvolvendo para a web, para CLI (Command-Line In- 
terface) e até para desktop (existem bons projetos e frameworks que pos- 
sibilitam o desenvolvimento para desktop utilizando o PHP). Com isso 
podemos criar soluções muito simples e outras mais complexas e não se 
faz necessário praticar TDD 100% do tempo. 

Um formulário de contato criado com HTML e PHP, a não ser que 
tenha uma regra muito complexa, não necessita que TDD seja levado à 
risca; já um carrinho de compras com a possibilidade de aplicação de 
descontos seguindo diversas regras merece uma atenção especial. 

Nestas decisões a experiência do desenvolvedor sempre indicará a ne- 
cessidade ou não da prática de TDD. 











11.2 100% DE COBERTURA DE CÓDIGO? 


Cobertura de código é a métrica que nos diz a quantidade de código que está 
testada e a quantidade de código em que nenhum teste o exercita. Uma cober- 
tura de código de 100% indica que todo código de produção tem ao menos 
um teste passando por ele. 

Muitas pessoas discutem a necessidade de ter 100% de cobertura em um 
código. Mas, na verdade, não há problemas em códigos que não tenham 100% 
de cobertura de testes de unidade. Uma equipe deve ter como meta buscar 
sempre a maior cobertura possível; mas essa é uma meta que provavelmente 
ela não irá alcançar. Alguns trechos de código simplesmente não valem a pena 
serem testados de maneira isolada, ou por serem simples demais para isso. 
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Um outro exemplo de código que não vale a pena ser testado são getters e 
setters. Geralmente eles são gerados pelo Netbeans (ou outra IDE que esteja 
utilizando), e existem aos milhares pelo sistema. Escrever testes exclusivos 
para eles é pura perda de tempo. 

Um desenvolvedor deve cobrir seu código de testes, mas pode usar testes 
de diferentes níveis para isso (testes de unidade, de integração, de sistema). 
Escrever testes de unidade inúteis, apenas para chegar nos 100% de cobertura, 
é desperdício. 





MAS COMO FAZER ESSA MÉTRICA SER ÚTIL? 


Configure a métrica para ignorar getters e setters, e todas as outras 
classes para as quais você já sabe que não escreverá testes. Desse jeito, a 
métrica pode passar a ser mais útil. Para ignorar a métrica para algum 





método ou classe, utilizamos a anotação EcodeCoverageIgnore, na- 
tivo do PHPUnit. 











11.3 DEVO TESTAR CÓDIGOS SIMPLES? 


Muitos desenvolvedores possuem essa heurística: “se o código é simples, en- 
tão não preciso testá-lo”. A regra pode até fazer algum sentido, mas ela é in- 
completa. 

Alguns trechos de código não merecem ser testados mesmo. Getters e set- 
ters, por exemplo, que geralmente são gerados através de sua IDE favorita, não 
precisam de testes próprios. Alguns construtores (que muitas vezes também 
são gerados automaticamente) também não precisam ser testados. Métodos 
que repassam a invocação do seu método para um método de uma de suas 
dependências e por isso só possuem uma única linha talvez também não pre- 
cisam ser testados. 

Mas tenha cuidado para não achar que todo método é simples. Muitos 
bugs caros são gerados por apenas uma linha de código. Lembre-se que, no 
momento em que o desenvolvedor escreve o código, ele parece simples aos 
olhos dele. Mas é fato que esse código sofrerá alterações no futuro; e muito 
provavelmente por um outro desenvolvedor. Como garantir que as alterações 
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feitas não façam com que as regras de negócio antigas parem de funcionar? 
Testes são necessários. 

Portanto, cuidado na hora de julgar se um código merece ou não ser tes- 
tado. Na dúvida, teste. Lembre-se que todo código é considerado culpado até 
que se prove inocente. 


11.4 ERROS COMUNS DURANTE A PRÁTICA DE TDD 


Ao praticar TDD, desenvolvedores às vezes cometem alguns deslizes que po- 
dem prejudicar o feedback da prática [15]. 

Escrever o teste e não o ver falhar pode não ser uma boa ideia. Se o desen- 
volvedor escreve um teste achando que ele falharia, mas ele passa, algo está 
errado. Ou ele não entende muito bem o código de produção que existe, ou 
o teste não está bem implementado. 

A ideia de também ver o teste passar rapidamente é justamente para que 
você “teste o teste”. Teste automatizado é código; e esse código pode conter 
bugs. Ao ver o teste passar, você garantiu que o teste fica vermelho ou verde 
na hora certa. 

Refatorar também é um passo importante do ciclo de TDD. Como dis- 
cutido ao longo do livro, TDD faz com que você escreva código simples fre- 
quentemente. Mas o simples pode não ser a melhor solução para o problema. 
Para chegar nela, o desenvolvedor deve refatorar seu código constantemente. 
Em um de meus estudos, observei que a grande maioria dos desenvolvedores 
diz esquecer da etapa de refatoração e partir logo para o próximo teste de 
maneira frequente. Isso pode não ser uma boa ideia. 

Não começar pelo cenário mais simples e ir evoluindo aos poucos tam- 
bém pode gerar código complexo desnecessário. Ao começar pelo cenário 
simples, o desenvolvedor garante que irá escrever a menor quantidade de 
código para fazer o teste passar. Evoluir aos poucos ajuda o desenvolvedor 
a aprender mais sobre o problema e ir evoluindo o código de maneira mais 
sensata. 

Os passos de TDD fazem sentido. Mas, novamente, use seu bom senso e 
experiência na hora de decidir usá-los ou não. 
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11.5 COMO CONVENCER SEU CHEFE SOBRE TDD? 


Geralmente um programador que nunca praticou TDD tem essa dúvida: será 
que TDD realmente ajuda na qualidade do código? E na redução de defeitos? 
Ele aumenta ou diminui a produtividade, afinal? Mas como toda e qualquer 
prática em engenharia de software, é muito difícil avaliar e chegar a uma con- 
clusão exata sobre seus ganhos e benefícios. 

Ao longo do livro, citamos diversas vantagens da escrita de testes e TDD. 
Maior qualidade externa, interna (do ponto de vista de implementação e pro- 
jeto de classes), produtividade (testes manuais no fim saem mais caros), entre 
outras. 

Nos últimos anos, a comunidade acadêmica vem rodando diversos exper- 
imentos para tentar mostrar de maneira empírica que TDD realmente ajuda 
no processo de desenvolvimento de software. Alguns desses estudos são feitos 
por professores bastante conhecidos na comunidade, como a prof. Laurie 
Williams (North Carolina State University) e o prof. David Janzen (California 
Polytechnic State University). 

Algumas dessas pesquisas investigam o fato de TDD reduzir o número de 
defeitos de um software; já outros investigam o fato de TDD produzir código 
de melhor qualidade. Alguns até pesquisam por indícios de aumento de pro- 
dutividade. A seguir, listo alguns desses estudos que podem ser usados para 
convencer seu chefe. 


Estudos na indústria 


Janzen [24] mostrou que programadores usando TDD na indústria pro- 
duziram código que passaram em aproximadamente 50% mais testes caixa- 
preta do que o código produzido por grupos de controle que não usavam 
TDD. Além do mais, o grupo que usava TDD gastou menos tempo de- 
bugando. Janzen também mostrou que a complexidade dos algoritmos era 
muito menor e a quantidade e cobertura dos testes era maior nos códigos es- 
critos com TDD. 

Um estudo feito pelo Maximillien e Williams [14] mostrou uma redução 
de 40-50% na quantidade de defeitos e um impacto mínimo na produtividade 
quando programadores usaram TDD. 
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Outro estudo feito por Lui e Chan [11] comparando dois grupos, um 
utilizando TDD e o outro escrevendo testes apenas após a implementação, 
mostrou uma redução significante no número defeitos. Além do mais, os de- 
feitos que foram encontrados eram corrigidos mais rapidamente pelo grupo 
que utilizou TDD. O estudo feito por Damm, Lundberg e Olson [12] também 
mostra uma redução significante nos defeitos. 

O estudo feito por George e Williams [13] mostrou que, apesar de TDD 
poder reduzir inicialmente a produtividade dos desenvolvedores mais inex- 
perientes, o código produzido passou entre 18% a 50% mais em testes caixa- 
preta do que códigos produzidos por grupos que não utilizavam TDD. Esse 
código também apresentou uma cobertura entre 92% a 98%. Uma análise 
qualitativa mostrou que 87.5% dos programadores acreditam que TDD facil- 
itou o entendimento dos requisitos e 95.8% acreditam que TDD reduziu o 
tempo gasto com debug. 78% também acreditam que TDD aumentou a pro- 
dutividade da equipe. Entretanto, apenas 50% acreditam que TDD ajuda a 
diminuir o tempo de desenvolvimento. Sobre qualidade, 92% acreditam que 
TDD ajuda a manter um código de maior qualidade e 79% acreditam que ele 
promove um design mais simples. 

Nagappan [31] mostrou um estudo de caso na Microsoft e na IBM e os 
resultados indicaram que o número de defeitos de quatro produtos diminuiu 
entre 40% a 90% em relação a projetos similares que não usaram TDD. Entre- 
tanto, o estudo mostrou também TDD aumentou o tempo inicial de desen- 
volvimento entre 15% a 35%. 

Langr [25] mostrou que TDD aumenta a qualidade código, provê uma fa- 
cilidade maior de manutenção e ajuda a produzir 33% mais testes comparados 
a abordagens tradicionais. 


Estudos na academia 


Um estudo feito por Erdogmus et all [23] com 24 estudos de graduação 
mostrou que TDD aumenta a produtividade. Todavia, nenhuma diferença de 
qualidade no código foi encontrada. 

Outro estudo feito por Janzen[8] com três diferentes grupos de alunos 
(cada um deles usando uma abordagem diferente: TDD, test-last, sem testes), 
mostrou que o código produzido pelo time que fez TDD usou melhor con- 
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ceitos de orientação a objetos e as responsabilidades foram separadas em 13 
diferentes classes enquanto que os outros times produziram um código mais 
procedural. O time de TDD também produziu mais código e entregou mais 
funcionalidades. Os testes produzidos por esse time teve duas vezes mais as- 
serções que os outros e cobriu 86% mais branches do que o time test-last. 
Além do mais, as classes testadas tinham valores de acoplamento 104% menor 
do que as classes não testadas e os métodos eram, na média, 43% menos com- 
plexos do que os não-testados. 

O estudo de Müller e Hagner [16] mostrou que TDD não resulta em mel- 
hor qualidade ou produtividade. Entretanto, os estudantes perceberam um 
melhor reúso dos códigos produzidos com TDD. Steinberg [35] mostrou que 
código produzido com TDD é mais coeso e menos acoplado. Os estudantes 
também reportaram que os defeitos eram mais fáceis de serem corrigidos. 
O estudo do Edwards [18] com 59 estudantes mostrou que código produzido 
com TDD tem 45% menos defeitos e faz com que o programador se sinta mais 
à vontade com ele. 


11.6 TDD EM SISTEMAS LEGADOS 


A grande dificuldade de se praticar TDD (e testes de unidade) em sistemas 
legados é que geralmente eles apresentam uma grande quantidade de código 
procedural. Códigos procedurais geralmente contêm muitas linhas de código, 
lidam com diferentes responsabilidades, acessam banco de dados, modificam 
a interface do usuário, o que os tornam difíceis de serem testados. 

Nesses casos, a sugestão é para que o desenvolvedor, antes de começar a 
refatorar o legado, escreva testes automatizados da maneira que conseguir. Se 
conseguir escrever um teste de unidade, excelente. Mas caso não consiga, en- 
tão ele deve começar a subir o nível até conseguir escrever um teste. Em apli- 
cações legadas web, por exemplo, o desenvolvedor pode começar com testes 
de sistema, para garantir o comportamento do sistema. 

Com esses testes escritos, o desenvolvedor conseguirá refatorar o código 
legado problemático que está por baixo, e ao mesmo tempo garantir a qual- 
idade do que está fazendo. Nessa refatoração, o desenvolvedor deve criar 
classes menores e mais coesas e já escrever testes de unidade para elas. 
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Durante essa reescrita, pode ser que o desenvolvedor sinta a necessidade 
de escrever testes “feios”, como testes para testar stored procedures ou coisas 
do tipo. Nesses casos, escreva o teste, implemente a nova solução, elimine 
a stored procedure bem como o seu teste. Em sistemas legados, não tenha 
medo de escrever código de teste que será jogado fora depois. Se fizermos 
uma analogia com a engenharia nesse momento, imagine que esses códigos 
sejam como os andaimes utilizados durante a obra. Eles não fazem parte do 
produto final, estão lá apenas para ajudar no desenvolvimento. 

Por mim, essa é a sugestão. Escreva testes para o sistema legado da 
maneira que conseguir, refatore o código já criando uma bateria de testes 
amigável. Ao final, caso faça sentido, jogue fora o código legado bem como 
testes que não são mais úteis. 

A dificuldade em se testar sistemas legados não se aplica para novas fun- 
cionalidades. Nelas, o desenvolvedor tem a chance de escrever um código 
melhor e mais fácil de ser testado. Alguns padrões de projeto, como o Adapter, 
ajudam-no a “conectar” código bem escrito com o legado que deve ser man- 
tido. 


11.7 CONCLUSÃO 


TDD é uma excelente ferramenta, deve constar no cinto de utilidades de todo 
desenvolvedor, mas obviamente deve ser usada nos momentos certos. Está 
em um momento complicado do desenvolvimento daquela classe? Use TDD. 
Está em uma situação em que não há muitas dúvidas sobre o que fazer? Não 
se sinta mal por escrever testes após a implementação. 


Lembre-se, o objetivo final é escrever código de qualidade. 
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E agora? 


Agora que TDD já foi discutido sob todos os pontos de vista, qual o próximo 
passo? Neste capítulo, finalizo a discussão apontando para outras excelentes 
referências sobre o assunto, e quais os próximos passos para o praticante. 


12.1 COMO APRENDER MAIS AGORA? 


A referência mais famosa sobre TDD é o livro do Kent Beck, intitulado Test- 
Driven Development: By Example, um livro bem introdutório sobre TDD. Ele 
discute aos poucos como escrever os testes antes, como ser simples, o que são 
baby steps etc. Ao longo do livro, ele cria uma classe Dinheiro, que real- 
iza operações financeiras em unidades monetárias distintas. Talvez seja uma 
ótima referência para quem nunca leu nada sobre o assunto, e quer começar. 

Um excelente livro sobre o tema é o famoso Growing Object Oriented 
Software, Guided by Tests, escrito por Steve Freeman e Nat Pryce. Neste 
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livro, os autores mostram como utilizar TDD pode ajudar no design de suas 
classes. Ambos os autores são famosos na comunidade por suas diversas con- 
tribuições para a comunidade ágil e código aberto. É um livro que vale a pena 
ser lido. 

Falando mais sobre design de classes, um bom livro é o Agile Software 
Development, Principles, Patterns, and Practices do Robert Martin. Nele, são 
discutidos os vários princípios de orientação a objetos de maneira profunda. 
Este livro contém um apêndice sobre o assunto, mas com certeza o livro do 
Uncle Bob é uma excelente referência para quem deseja se aprofundar em 
design orientado a objetos. 

Por fim, aponto também para o blog da Caelum (http://blog.caelum.com. 
br) e meu blog pessoal (http://www.aniche.com.br) , onde tenho escrito bas- 
tante conteúdo sobre o assunto. Os posts, aliás, foram uma grande motivação 
para a escrita desse livro. 

Caso você prefira uma abordagem com cursos presenciais, certamente os 
cursos da Caelum, os quais ajudei a criar, são uma excelente fonte de apren- 
dizado: 


http://www.caelum.com.br/cursos/agile/ 


12.2 E QUANTO AO CÓDIGO LEGADO? 


Código legado causa dores de cabeça em qualquer linguagem, principalmente 
quando falamos sobre o PHP, visto que a linguagem tem evoluído a uma 
velocidade surpreendente. No entanto, poucos são os desenvolvedores que 
seguem esta evolução. Com isto, os códigos legados em PHP tendem a ser 
mais problemáticos que comumente encontramos em outras linguagens. Mas 
de fato como devemos proceder nestas situações? 

É muito difícil pensar em iniciar a prática de TDD em código legado, 
visto que TDD é uma orientação para a criação de seu código final, e neste 
caso tal código já existe. Mais ainda, ao longo do livro vimos que é bastante 
complicado testar código pouco coeso e muito acoplado, que é o que acontece 
em códigos legados: temos trechos de código gigantescos, que misturam as 
mais diferentes responsabilidades, como acesso a banco de dados, HTML, 
lógica de negócio etc. 
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Nesses casos, talvez uma boa ideia seja esquecer um pouco TDD e pen- 
sar em testes automatizados. E testes automatizados no nível que mais faça 
sentido para aquele pedaço do sistema. Por exemplo, às vezes não é possível 
escrever um teste de unidade, isolado, para aquela funcionalidade; nesse caso, 
vá para um teste de sistema. Ou seja, aquele tipo de teste que abre o browser 
e interage com a aplicação. Fazer isso não é tão difícil e ferramentas como 
Selenium [10] são importantes. 

E, claro, para novas funcionalidades, use TDD. Abuse dele. Faça testes e 
observe os feedbacks para fazer com que seu código fique fácil de ser man- 
tido ao final. Para possibilitar a prática, é recomendável separar as novas fun- 
cionalidades em novos namespaces (pacotes/pastas), fazendo para isto o uso 
de diversos padrões de projeto como Adapter e Facade, possibilitando a inte- 
gração das novas funcionalidades com o sistema já em funcionamento. 

Em um momento oportuno, mesmo aquele trecho de código horroroso, 
coberto apenas por testes de sistema, será reescrito. E aí, obviamente, use 
TDD, e cubra as funcionalidades com testes de unidade, simples, curtos e de 
rápido feedback. Depois, você até poderá jogar fora a bateria de testes de 
sistema escrita só para encobrir o fato da má qualidade do código. 

Não há uma receita de bolo para escrever testes em sistemas legados. 
Você, sem dúvida, precisará sujar suas mãos. 


12.3 DIFICULDADE NO APRENDIZADO 


Nos últimos anos, tenho dado diversas aulas e workshops sobre o assunto, e 
hoje posso afirmar que a maior dificuldade na hora de se praticar TDD são: 


e Falta de conhecimento em orientação a objetos. Quando o desen- 
volvedor não conhece orientação a objetos a fundo, ele sente dificul- 
dades no momento da escrita do teste. Entender bem os conceitos e 
princípios do paradigma o ajudará a aprender TDD mais facilmente. 


e Pensar em cenários para os testes. Pensar em cenários não é algo tão 
natural. Lembre-se que um teste automatizado é muito parecido com 
um teste manual. Imagine quais os cenários você testaria em sua apli- 
cação como um todo, e vá descendo de nível até imaginar como aquela 
classe deve responder de acordo com as diferentes entradas. 
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Como toda nova prática introduzida em um ambiente de trabalho, é nor- 
mal que a produtividade caia no começo. Para que TDD torne-se natural 
para a equipe, é necessário que ela pratique constantemente. Existem diver- 
sos exercícios e vídeos explicativos para que o desenvolvedor consiga praticar 
e dominar melhor a prática. 

Junto com a Caelum, escrevi um curso online sobre o assunto. Ele 
pode ser encontrado no próprio site da Caelum (http://www.caelum.com.br/ 
online). Lá, produzi um conjunto de vídeos bem didáticos sobre a utilização 
de TDD em um sistema de leilões. Talvez essa seja uma ótima maneira para 
você treinar sua equipe também. 


12.4 COMO INTERAGIR COM OUTROS PRATICANTES? 


Como falado no começo do livro, criei um grupo de discussão no Google 
Groups. Você pode se cadastrar em https://groups.google.com/forum/#! 
forum/tdd-no-mundo-real. 

Também abuse do GUJ, uma comunidade de perguntas e respostas para 
tirar dúvidas técnicas: http://www.guj.com.br/ 

Existem grupos específicos para discussões a respeito do PHP que en- 
volve não apenas TDD mas todo o conjunto de boas práticas a respeito da 
linguagem, o principal deles é o grupo PHP Brasil no Facebook https://www. 
facebook.com/groups/nao.tem.biscoito. Neste grupo você poderá acompan- 
har e participar das discussões a respeito da evolução da linguagem, orien- 
tação a objetos, design e arquitetura de software. 


12.5 CONCLUSÃO FINAL 


Testar é vital para a qualidade de qualquer sistema. Lembre-se que quali- 
dade é algo de que não podemos abrir mão, dada a importância que sistemas 
de computador têm hoje perante a sociedade. Ao longo deste livro, tentei 
mostrar como pode ser fácil e divertida a escrita de testes automatizados. Es- 
pero ter mostrado também que a busca por testabilidade acaba guiando o 
programador a um design de classes melhor e mais sustentável. 


Agora depende de você. É hora de escrever testes! 
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Apéndice: principios SOLID 


Ao longo do curso, discutimos diversos principios de design, de forma as 
vezes informal. Este apéndice vem consolidar os principios apresentados ao 
longo do livro. Para maiores informações sobre eles, é sugerido que o leitor 
busque os trabalhos do Robert Martin [29]. 


13.1 SINTOMAS DE PROJETOS DE CLASSES EM 
DEGRADAÇÃO 


Diz-se que um projeto de classes está degradando quando ele começa a ficar 
difícil de evoluir, o reúso de código se torna mais complicado do que repetir 
o trecho de código, ou o custo de se fazer qualquer alteração no projeto de 
classes se torna alto. 


Robert Martin enumerou alguns sintomas de projeto de classes em 
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degradação, chamados também de maus cheiros de projeto de classes. Esses 
sintomas são parecidos com os maus cheiros de código (code smells), mas em 
um nível mais alto: eles estão presentes na estrutura geral do software ao invés 
de estarem localizados em apenas um pequeno trecho de código. 

Esses sintomas podem ser medidos de forma subjetiva e algumas vezes 
de forma até objetiva. Geralmente, esses sintomas são causados por violações 
de um ou mais princípios de projeto de classes. Muitos desses problemas 
são relacionados à gerência de dependências. Quando essa atividade não é 
feita corretamente, o código gerado torna-se difícil de manter e reusar. Entre- 
tanto, quando bem feita, o software tende a ser flexível, robusto e suas partes 
reusáveis. 


Rigidez 

Rigidez é a tendência do software em se tornar difícil de mudar, mesmo 
de maneiras simples. Toda mudança causa uma cascata de mudanças subse- 
quentes em módulos dependentes. Quanto mais módulos precisam ser mod- 
ificados, maior é a rigidez do projeto de classes. 

Quando um projeto de classes está muito rígido, não se sabe com segu- 
rança quando uma mudança terá fim. Mudanças simples passam a demorar 
muito tempo até serem aplicadas no código e frequentemente acabam su- 
perando em várias vezes a estimativa de esforço inicial. Frases como “isto 
foi muito mais complicado do que eu imaginei 

tornam-se populares. Neste momento, gerentes de desenvolvimento 
começam a ficar receosos em permitir que os desenvolvedores consertem 
problemas não críticos. 


Fragilidade 


Fragilidade é a tendência do software em quebrar em muitos lugares difer- 
entes toda vez que uma única mudança acontece. Frequentemente, os novos 
problemas ocorrem em áreas não relacionadas conceitualmente com a área 
que foi mudada, tornando o processo de manutenção demasiadamente cus- 
toso, complexo e tedioso. 

Consertar os novos problemas usualmente passa a resultar em outros 
novos problemas e assim por diante. Infelizmente, módulos frágeis são co- 
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muns em sistemas de software. São estes os módulos que sempre aparecem 
na lista de defeitos a serem corrigidos. Além disto, desenvolvedores começam 
a ficar receosos de alterar certos trechos de código, pois sabem que estes es- 
tão tão frágeis que qualquer mudança simples fatalmente acarretará na intro- 
dução de problemas inesperados e de naturezas diversas. 


Imobilidade 


Imobilidade é a impossibilidade de se reusar software de outros projetos 
ou de partes do mesmo projeto. Neste cenário, o módulo que se deseja reuti- 
lizar frequentemente tem uma bagagem muito grande de dependências e não 
possui código claro. Depois de muita investigação, os arquitetos descobrem 
que o trabalho e o risco de separar as partes desejáveis das indesejáveis são 
tão grandes, que o módulo acaba sendo reescrito em vez de reutilizado. 


Viscosidade 


Quando uma mudança deve ser realizada, geralmente há várias opções 
para realizar tal mudança. Quando as opções que preservam o projeto de 
classes são mais difíceis de serem implementadas do que aquelas que não o 
preservam, há alta viscosidade de projeto de classes. Neste cenário, é fácil 
fazer a “coisa errada” e é difícil fazer a “coisa certa”, ou seja, é difícil preservar 
e aprimorar o projeto de classes. 


Complexidade desnecessária 


Detecta-se complexidade desnecessária no projeto de classes quando ele 
contém muitos elementos inúteis ou não utilizados (dead code). É comum 
ocorrer quando há muito projeto inicial (up-front design) e não se segue uma 
abordagem de desenvolvimento iterativa e incremental, de modo que os pro- 
jetistas tentam prever uma série de futuros requisitos para o sistema e con- 
cebem um projeto de classes demasiadamente flexível ou desnecessariamente 
sofisticado. 

Frequentemente apenas algumas previsões acabam se concretizando ao 
longo do tempo e, neste meio período, o projeto de classes carrega o peso de 
elementos e construções não utilizados. O software então se torna complexo 
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e difícil de ser entendido. Projetos com complexidade muito alta comumente 
afetam a produtividade, porque quando os desenvolvedores o herdam, eles 
gastam muito tempo aprendendo as nuances do projeto de classes antes que 
possam efetivamente estendê-lo ou mantê-lo confortavelmente. 


Repetição desnecessária 


Quando há repetição de trechos de código, é sinal de que uma abstração 
apropriada não foi capturada durante o processo de projeto de classes (ou in- 
clusive na análise). Esse problema é frequente e é comum encontrar softwares 
que contenham dezenas e até centenas de elementos com códigos repetidos. 

Descobrir a melhor abstração para eliminar a repetição de código geral- 
mente não está na lista de itens de alta prioridade dos desenvolvedores, de 
maneira que a resolução do problema acaba sendo eternamente postergada. 
Também, o sistema se torna cada vez mais difícil de entender e principalmente 
de manter, pois os problemas encontrados em uma unidade de repetição de- 
vem ser corrigidos potencialmente em toda repetição, com o agravante de que 
uma repetição pode ter forma ligeiramente diferente de outra. 


Opacidade 


Opacidade é a tendência de um módulo ser difícil de ser entendido. Códi- 
gos podem ser escritos de maneira clara e expressiva ou de maneira “opaca” e 
complicada. A tendência de um código é se tornar mais e mais opaco à me- 
dida que o tempo passa e, para que isso seja evitado, é necessário um esforço 
constante em manter esse código claro e expressivo. 

Uma maneira para prevenir isso é fazer com que os desenvolvedores se 
ponham no papel de leitores do código e refatorem esse código de maneira 
que qualquer outro leitor poderia entender. Além disso, revisões de código 
feitas por outros desenvolvedores é também uma possível solução para man- 
ter o código menos opaco. 


13.2 PRINCÍPIOS DE PROJETO DE CLASSES 


Todos os problemas citados na seção anterior podem ser evitados pelo uso 
puro e simples de orientação a objetos. A máxima da programação orientada 
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a objetos diz que classes devem possuir um baixo acoplamento e uma alta 
coesão. 

Alcançando esse objetivo, mudanças no código seriam executadas mais 
facilmente; alterações seriam feitas em pontos únicos e a propagação de mu- 
danças seria bem menor. Com as abstrações bem estabelecidas, novas fun- 
cionalidades seriam implementadas através de novo código, sem a necessi- 
dade de alterações no código já existente. Necessidades de evolução do pro- 
jeto de classes seriam feitas com pouco esforço, já que módulos dependeriam 
apenas de abstrações. 

Mas alcançar tal objetivo não é tarefa fácil. Criar classes pouco acopladas 
e altamente coesas demanda um grande esforço por parte do desenvolvedor 
e requer grande conhecimento e experiência no paradigma da orientação a 
objetos. 

Os princípios comentados nesta seção são muito discutidos por Robert 
Martin em vários de seus livros e artigos publicados. Esses princípios são 
produto de décadas de experiência em engenharia de software. Segundo ele, 
esses princípios não são produtos de uma única pessoa, mas sim da integração 
de pensamentos e trabalhos de um grande número de desenvolvedores de 
software e pesquisadores, e visam combater todos os sintomas de degradação 
discutidos anteriormente. 


Conhecidos pelo acrônimo SOLID (sólido, em português), são eles: 


e Princípio da responsabilidade única (Single-Responsibility Principle — 
SRP); 


e Princípio do aberto-fechado (Open-Closed Principle — OCP); 


e Principio de substituição de Liskov (Liskov Substitution Principle — 
LSP); 


e Princípio da inversão de dependência (Dependency Inversion Principle 
— DIP); 


e Princípio da segregação de interfaces (Interface Segregation Principle — 
ISP). 
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Princípio da responsabilidade única 


O termo coesão define a relação entre os elementos de um mesmo mó- 
dulo. Isso significa que os todos elementos de uma classe que tem apenas 
uma responsabilidade tendem a se relacionar. Diz-se que uma classe como 
essa é uma classe que possui alta coesão (ou que é coesa). Já em uma classe 
com muitas responsabilidades diferentes, os elementos tendem a se relacionar 
apenas em “grupos”, ou seja, com os elementos que tratam de uma das respon- 
sabilidades da classe. Sobre esse tipo de classe, diz-se que ela possui uma baixa 
coesão (ou que não é coesa). Robert Martin altera esse conceito de coesão e 
a relaciona com as forças que causam um módulo ou uma classe a mudar. 
No caso, o Princípio de responsabilidade única diz que uma classe deve ter 
apenas uma única razão para mudar. 

Esse princípio é importante no momento em que há uma alteração em 
alguma funcionalidade do software. Quando isso ocorre, o programador pre- 
cisa procurar pelas classes que possuem a responsabilidade a ser modificada. 
Supondo uma classe que possua mais de uma razão para mudar, isso sig- 
nifica que ela é acessada por duas partes do software que fazem coisas difer- 
entes. Fazer uma alteração em uma das responsabilidades dessa classe pode, 
de maneira não intencional, quebrar a outra parte de maneira inesperada. Isso 
torna o projeto de classes frágil. 


Princípio do aberto-fechado 


O Princípio do aberto-fechado, cunhado por Bertrand Meyer, diz que as 
entidades do software (como classes, módulos, funções etc.) devem ser aber- 
tas para extensão, mas fechadas para alteração. Se uma simples alteração re- 
sulta em uma cascata de alterações em módulos dependentes, isso cheira à 
rigidez. O princípio pede então para que o programador sempre refatore as 
classes de modo que mudanças desse tipo não causem mais modificações. 

Quando esse princípio é aplicado de maneira correta, novas alterações 
fazem com que o programador adicione novo código, e não modifique o an- 
terior. Isso é alcançado através da criação de abstrações para o problema. 
Linguagens orientadas a objetos possuem mecanismos para criá-las (con- 
hecidos como interfaces em linguagens como Java ou C&). Através dessas 
abstrações, o programador consegue descrever a maneira com que uma de- 
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terminada classe deve se portar, mas sem se preocupar com como essa classe 
faz isso. 


Princípio de substituição de Liskov 


Esse princípio, que discute sobre tipos e subtipos, criado por Barbara 
Liskov em 1988, é importante já que herança é uma das maneiras para se su- 
portar abstrações e polimorfismo em linguagens orientadas a objetos e, como 
visto anteriormente, o Princípio do aberto-fechado se baseia fortemente na 
utilização desses recursos. 

O problema é que utilizar herança não é tarefa fácil, pois o acoplamento 
criado entre classe filha e classe pai é grande. Fazer as classes filhas re- 
speitarem o contrato do pai, e ainda permitir que mudanças na classe pai não 
influenciem nas classes filhas requer trabalho. 

O Princípio de Liskov diz que, se um tipo S é subclasse de um tipo T, então 
objetos do tipo T podem ser substituídos por objetos do tipo S, sem alterar 
nenhuma das propriedades desejadas daquele programa. 

Um clássico exemplo sobre Princípio de substituição de Liskov é o ex- 
emplo dos Quadrados e Retângulos. Imagine uma classe Retângulo. Um 
retângulo possui dois lados de tamanhos diferentes. Imagine agora uma 
classe Quadrado (figura geométrica que possui todos os lados com o mesmo 
tamanho) que herde de Retângulo. A única alteração é fazer com que os 
dois lados tenham o mesmo tamanho. Apesar de parecer lógico, afinal um 
Quadrado é um Retângulo com apenas uma condição diferente, a classe 
Quadrado quebra o Princípio de Liskov: a precondição dela é mais forte do 
que a do quadrado, afinal os dois lados devem ter o mesmo tamanho. 

Quebras do Princípio de Liskov geralmente levam o programador a que- 
brar o princípio do OCP também. Ele percebe que, para determinados sub- 
tipos, ele precisa fazer um tratamento especial, e acaba escrevendo condições 
nas classes clientes que fazem uso disso. 


Princípio da inversão de dependências 


Classes de baixo nível, que fazem uso de infraestrutura ou de outros de- 
talhes de implementação podem facilmente sofrer modificações. E, se classes 
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de mais alto nível dependerem dessas classes, essas modificações podem se 
propagar, tornando o código frágil. 


O Princípio de inversão de dependências se baseia em duas afirmações: 


e Módulos de alto nível não devem depender de módulos de baixo nível. 
Ambos devem depender de abstrações; 


e Abstrações não devem depender de detalhes. Detalhes devem depen- 
der de abstrações. 


Em resumo, as classes devem, na medida do possível, acoplar-se sempre 
com módulos mais estáveis do que ela própria, já que, como as mudanças 
em módulos estáveis são menos prováveis, raramente essa classe precisará ser 
alterada por mudanças em suas dependências. 


Princípio da segregação de interfaces 


Acoplar-se com uma interface de baixa granularidade (ou gordas, do 
termo em inglês fat interfaces) pode ser perigoso, já que qualquer alteração 
que um outro cliente forçar nessa interface poderá ser propagada para essa 
classe. 

O Princípio da segregação de interfaces diz que classes cliente não de- 
vem ser forçados a depender de métodos que eles não usam. Quando uma 
interface não é coesa, ela contém métodos que são usados por um grupo de 
clientes, e outros métodos que são usados por outro grupo de clientes. Apesar 
de uma classe poder implementar mais de uma interface, o princípio diz que 
o cliente da classe deve apenas depender de interfaces coesas. 


13.3 CONCLUSÃO 


Todos os princípios discutidos na seção anterior tentam diminuir os possíveis 
problemas de projeto de classes que possam eventualmente aparecer. Discu- 
tir o que é um bom projeto de classes é algo difícil; mas é possível enumerar 
algumas das características desejáveis: isolar elementos reusáveis de elemen- 
tos não reusáveis, diminuir a propagação de alterações em caso de uma nova 
funcionalidade. 
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Um bom programador OO deve conhecer e aplicar esses princípios ao 
longo de sua base de código. 
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